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ABSTRACT 



The United States Navy is currently implementing a plan 
to consolidate the wholesale supply functions of the Naval 
Air Station at Alameda and the Naval Supply Center at Oakland. 
Improving supply support of the Naval Air Rework Facility 
Alameda in general and stock availability in particular is a 
vital part of the plan. Demand forecasting by workload driven 
material requirements planning (MRP) is being considered as 
a means to improve stock availability. This thesis begins 
with an overview of the MRP technique and the current supply 
support of NARF Alameda. It proceeds with the description 
and evaluation of a temporary MRP system that is currently 
implemented and uses it as a background for development of 
an MRP system that is designed to operate in a maintenance 
oriented environment in general and at NARF Alameda in 
particular. Finally, suggestions are made for transition 
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I. INTRODUCTION 



The DOD Material Distribution Study (DODMDS) [7:8] 
attempted to determine the number and locations of wholesale 
activities necessary to provide efficient and cost effective 
distribution of materials. As a consequence of the recommen- 
dations of that study, the Naval Supply System Command (NAVSUP) 
initiated the Shore Establishment Realignment (SER) which will 
consolidate the wholesale supply functions of the Naval Air 
Stations (NAS) at Alameda, North Island and Norfolk with the 
Naval Supply Centers at Oakland, San Diego and Norfolk, 
respectively. 

NAVSUP has specified that the consolidation is not to 
degrade the supply support provided currently by the NAS supply 
departments. However, it will be beneficial to the system-- 
and especially to the Naval Air Rework Facility (NARF) as one 
of the customers- - to achieve not only reduced costs, but also 
improved service. 

SER and the NARF's desire to maximize improvements has 
necessitated a basic reappraisal of the NARF/Supply System 
interfaces. The result [10] was identification of the fol- 
lowing problem areas and possible improvements: 

1. Response time, can be improved by:- 

a. Mechanized requirements submission 

b. Automated inventory control and materials handling 

2. Stock availability, can be improved by : - 

a. Demand forecasting by workload driven material 
requirements planning (MRP) . 
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This study was done as part o£ the NARF's effort to 
clearly identify the problem areas in its supply support and 
find the best solutions to those problems. This study attacks 
specifically the stock availability problem and justifies why 
MRP is the solution. 

The implementation of MRP is integrated into the consoli- 
dation process and the implementation of response time improve- 
ments in the system. As a result, the implementation of MRP 
consists of two phases :- 

I. Implementation of a temporary system that will run on 
existing equipment and will be used to gain experience 
with the system and build up the necessary data files. 

This phase will include the design of the target system. 

II. Implementation of the final system on the new computer- 
ized material handling equipment- -namely , NISTARS/ASKARS 
(Naval Integrated Storage and Retrieval System/Automated 
Storage, Kitting and Retrieval System). 

This thesis describes briefly the development and imple- 
mentation of Phase I and uses it as a background for a proposed 
design and integration of the final MRP system with the standard 
ASKARS software and database. 
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II. MATERIAL REQUIREMENTS PLANNING 



A. BACKGROUND: PRODUCTION AND INVENTORY CONTROL 

Production and inventory control emerged as independent 
management tools. Production control, in the very beginning, 
was one of the functions performed by the line foreman. He 
ordered materials, hired people and decided what, how and 
how much to produce. As his workload increased, the first 
task to be assigned to someone else was the ordering of 
materials. Along with that, there were also a few attempts 
to develop a scientific approach to production control. 
However, general applications did not develop prior to World 
War II. After the war, industry needed maximum production 
since there was an almost insatiable demand for products. 

The main problem was how to make more and more products, not 
necessarily how to make them more efficiently [1:XIII]. 

This environment gave a big push to production planning 
and many techniques evolved, mainly oriented towards pro- 
duction with little consideration of the related inventory 
problems. Among those techniques were Gantt charts [1:13.33], 
Line of Balance [1:13.23], Network Methods [1:13.33] and 
Linear Programming [1:13.45]. It seemed apparent that these 
techniques had great potential to improve both production and 
inventory control which frequently deal with uncertainty, 
especially because of the little attention these functions 
had received from management. 
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Inventory control, on the other hand, developed in a 
more "natural” way. The concept of economic lot sizing and 
reorder points was first presented by Ford Harris in 1915 
and later developed by R. H. Wilson in 1934 [14:3]. But it 
was only after World War II that that theory had seen real 
application, after stochastic inventory models were developed 
and could use this theory in a more realistic way. 

The biggest problem in applying the scientific techniques 
in industry has been the fact that companies were not ready 
for them because they had not begun to solve many of their 
basic problems in controlling production. Lists of materials 
and parts were not in existence. Production depended on the 
memories of people in the company. Under such conditions, no 
scientific method which needed data could be implemented 
[1:XIV] . 

The second decade after World War II has seen a reversal 
of that situation. Supply caught up with demand and low-cost 
high-quality products were available in large quantities. 
Meeting competition required tightly controlled factories and 
most efficient use of men, money and materials. The responsi 
bility to achieve the necessary improvements has been given 
to the production and inventory control function [1:XIV]. 

Production and inventory control were separate functions 
with conflicting natures. Lack of data and experience was 
another problem. Together they created a problem too serious 
to ignore. 
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The introduction of computers provided the means for 
solving many of the problems. The use of computers: 

1. Allows storing information, 

2. Enables processing and efficient use of that information. 

3. Makes the system more responsive because handling of 
data, updating and retrieving are facilitated. 

4. Allows integration of both production and inventory 
control . 

First attempts to use computers in production failed 
[17:3]. The main reasons were: 

1. Companies had failed to develop discipline in information 
handling . 

2. The system being implemented was a mechanized version of 
the manual system. Since the manual system was never 
taken seriously enough to work satisfactorily, there was 
no chance for the computerized system to succeed. 

However, those attempts established a sound foundation on 
which better systems were developed, supporting initially only 
parts of the various functions of production and inventory 
control. Later, integrated systems supported, or more accur- 
ately, maintained the whole production system. 

One of the techniques which emerged and benefitted from 
the use of computers was the Material Requirements Planning 
(MRP) method. This method, which is used as one module of 
the production and inventory control system, uses the pro- 
duction schedule as the basis for inventory control. By 
doing that, there are no longer two different systems, but 
one integrated system which: 

1. Uses the same data for both production and inventory 
control , 
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2. Provides built-in mutual feedback and response in the 
system and no longer depends on activities of separate 
functions in the organization. 

B. MATERIAL REQUIREMENTS PLANNING CONCEPT 

Material Requirements Planning (MRP) , or Requirements 
Planning System (RMS) as called by others [1:17.2], is a 
technique for determining the quantities of components that 
will be required to build a product or carry out a production 
schedule . 

The term "components" is usually used to cover both sub- 
assemblies and parts from which a product is made. As far as 
the technique is concerned, there is no difference between 
them and the only requirement is to know that they are 
required to build the item and in given quantities for 
assembling one product. 

The direct objective of the system is to generate require- 
ments in fairly precise time periods so that the right infor- 
mation will be available to get the required components into 
the regular production process, rather than using lists of 
"hot items" to complete the assembly of an order. 

A manufacturing environment, as opposed to maintenance, 
is the best for implementation of this technique because the 
output of the system is well defined in terms of the items 
being produced, the components from which they are composed, 
their quantities and their time schedule. Only a manufactur- 
ing environment can provide the inputs that MRP needs- -with 
sufficient accuracy--to ensure effective operation. 
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The MRP concept is described in Figure 1. The basis is 
the master production schedule, which is a "given*' to the MRP 
system. The production schedule states which products are 
to be produced and when. In addition to that, the system 
also uses two other files: 

1. Inventory file - This file contains data about all 
items used/produced in the organization. The information 
about each item includes elements such as quantities (on 
hand, on order), sources of supply , price , lead times and 
associated costs. 

2. Bill of Materials file - This file contains the 
product structure data for each product which may be produced 
by the company. In addition to quantities of subassemblies 
and parts, the file will also contain numbers of drawings or 
other documentation required in the production process. 




Figure 1: A Material Requirements Planning System 
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The most important data item in these two files is the 
item identification number (part number) . This is the common 
field that connects all files and allows direct access to get 
the required information for the computations. It is essen- 
tial to eliminate ambiguity in those numbers on the one hand 
and, on the other, to have meaningful numbers which may 
simplify operations of the system and prevent mistakes. 

The process by which requirements are determined is as 
follows. First, the master production schedule is used to 
determine which products will be produced in the following 
period. For each order, relevant data from the bill of ma- 
terials file is retrieved and added to the "file” of required 
materials. At this point, each product is "exploded" into 
its basic components and total quantities are compul;ed for 
each item (part number). 

It is important to note that the production schedule for 
more than one planning period can be used. But since the 
time the items will be needed is very important (it might be 
very costly to keep them when not needed), we would like to 
sum up requirements separately for each period and as close 
as possible to the day of use as lead-time allows. Adding 
the requirements for all periods and orders gives the "gross 
requirements," i.e., a list Of all components required to 
carry out the production schedule. 

When the gross requirements are available, they are com- 
pared with the information in the inventory file. For each 
item, the gross requirement is compared with the total of 
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quantities on hand and those on order which are due in the 
relevant period. If the gross requirement is greater, an 
order should be placed. A simple rule to determine the 
order quantity suggests itself- - order the amount which is 
missing. Thus, it may be that the same item will be required 
for the next period also. This requires a more sophisticated 
rule which will be discussed separately. 

The way the process was described is most fitting 
when there are no deviations from the production schedule. 
Obviously, this is not always the case. As it turns out, 
the same logic can also be used in a continuous operating 
environment (including deviations from schedule) by regen- 
eration of the requirements as described above. In other 
words, the updated production schedule is used periodically 
to recompute the requirements. This process is called a 
Schedule Regeneration System [4:99]. 

Another way to compute requirements without repeating 
all computations for periods which were previously analyzed 
is called the "Net Change Material Requirements Planning" 
[4:102]. The basic idea here is to keep track of the orig- 
inal gross requirements for each period and then to compute 
gross requirements for changes in the production schedule 
as they occur by adding/subtracting them according to the 
specific change in the schedule. This results in a new 
gross requirement which has to be compared to available 
stocks (on hand and on order) to give the net requirements. 
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The computation is relatively simple when the change is 
an addition of a job, but it becomes very complicated to keep 
track and "to free" allocated materials when the change is a 
deletion of a planned job. 

It may seem that the "net change" alternative is much 
better than the regeneration system. This is true if there 
are no changes in the schedule. But if this is not the case, 
continuous updating of the whole data base is required along 
with the necessity for incessantly reacting to the system's 
output. That usually creates a "nervous" reaction of the 
system, i,e,, order changes and manual follow-up, which is 
more a disadvantage than an advantage. Of course, there is 
always the trade-off between the "nervous reaction" and the 
lack of reaction of the system, A short (one month) cycle 
time (planning horizon) may provide a good compromise, thus 
justifying the use of the simpler regenerative system. 

Figures 2 and 3 describe the "regeneration" and net 
change alternatives. From the flow charts it can be seen 
that the "net change" algorithm is more complicated. But 
if there are only few changes in the production schedule, 
some work may be saved. 

C. ASSUMPTIONS AND PREREQUISITES 

Introduction of an MRP system as an inventory control 
tool in a manufacturing organization is not just a matter 
of management's decision. There are some assumptions and 
prerequisites about the environment in which MRP is to 
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Figure 3: *'Net Change" Material Requirements Planning. 
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be implemented. The preconditions for implementation of 
MRP are listed below: 

1 . Existence of Automated Data Processing (ADP) 

The amount of work involved in manual computation of 
requirements is prohibitively high. A manual MRP is imprac- 
tical except for very simple products. The assistance of 
computers is required for processing of massive numbers of 
lower- level items. 

2 . Existence of a Master Schedule, Bill of Materials 

File and Inventory Status File 

These files are the basic input for the MRP systems 
and it is obvious that without them the system would not work. 
But the existence of such files is not enough because files 
can have these names and contain different data than needed. 
The Master Schedule should be stated in terms of entries in 
the Bill of Materials file (BOM), i.e., having a product to 
be produced allows access to the Bill of Materials file to 
get a list of components and quantities required to produce 
that item. A similar relationship should exist also between 
the BOM file and the inventory file to obtain the status of 
each component needed. The common key here is the Item 
Identification Code (IIC). 

3 . Unambiguous Item Identification 

This is usually achieved through unique codes such as 
part numbers. Although this subject seems to be straight- 
forward and simple, it is actually very difficult to maintain 
a simple unambiguous identification method when dealing with 
hundreds of thousands of items coming from many sources. 
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4 . Data Integrity 



Files must be kept updated and consistent with each 
other. Changes in design require changes in the BOM file and 
may result in changes in quantities to be ordered. Therefore, 
all files should be updated simultaneously since changes in 
one may cause changes in another. 

5 . Known Lead-times 

At the very least, there should be estimates of lead- 
times to allow reordering on time. 

6 . Availability of Components 

All components of a product must be available when 
the production order is released. Although this assumption 
may not hold in some cases, it may result in simplification 
of the MRP model. A more complicated version may take into 
account the production schedule for a specific item and allow 
arrival of certain items during the production process. This, 
of course, is more difficult to implement and the benefits are 
outweighed by the problems it causes [4]. 

7 . Process Independence 

It is assumed that there is no interference between 
different production orders. The production master schedule 
should incorporate all relevant considerations. 

The existence of all these factors in an organization no 
more implies the applicability of the MRP model than their 
absence implies their inapplicability. Basically, an MRP is 
"applicable to manufacturing environments that are oriented 
towards fabrication of components" [4:42], and the problem of 
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satisfaction of preconditions may be solved if the decision 
is made to implement MRP. 

D. MRP SYSTEM OUTPUT 

What is the MRP system expected to produce? Basically, 
every production/ inventory control system is expected to 
provide the Inventory Control Manager with information that 
will answer the following three problems: 

1. What to buy? 

2. When to buy? 

3. How much to buy? 

The question of what to buy gets a straightforward answer 

from the system by computations of gross and net requirements. 

This is a "simple" decision when che production schedule is 

known and the composition of each product is fixed. Those 

two factors are preconditions of the MRP system. 

* 

The problems of when to buy and how much to buy are more 
complicated and interdependent. The decision may be affected 
by many external factors such as sale prices, seasonality, 
expected shortages because of instability of the market or 
other similar factors. Of course, such factors cannot be 
accounted for in a system which runs according to a prede- 
termined algorithm because they apply only to specific items, 
and the only simple way to improve results is to correct 
manually the "proposals" of the system. 

However, there are other factors which determine the 
quantities and timing. The basic factor is, again, the 
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production schedule. When it is split into specific tasks, 
an exact determination can be made as to how much is required 
at any point of time. When inventory (on hand and on order) 
is compared against requirements, the result is information 
about definite quantities which are to be available at certain 
times. Consideration of lead times gives the time for order- 
ing. 

The decision whether to follow that basic ordering 
schedule has still to consider trade-offs between ordering 
costs and holding costs since the same item may be required 
for more than one period of time. 

That problem is solved by the least unit cost method 
[4:511] which calculates the combined ordering and holding 
cost per unit for each period separately, for two periods 
combined, for three periods, and so on, and selects which- 
ever method produces the lowest unit costs. 

Even though we have discussed the output contents before, 
it should be recognized that the way it will be presented 
depends on the user (and the ADP responsiveness, of course!). 
If the organization is highly computerized, and its procure- 
ment activities interact with organizations which are also 
highly computerized, it is likely that the output will be 
magnetic tapes which will contain all purchasing orders. 

These tapes will be sent to the sellers, which in turn enter 
them directly into their automated system. (Such a method 
is used for procurements in the Israeli Navy.) 
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If the system is not that well developed, the purchasing 
order containing all data required to buy the item will be 
printed by the computer. Those orders will then have to be 
reviewed and processed. 

The MRP system may also produce many other management 
reports. These will usually concern specific problems which 
exist in the plant. Typical reports of this kind are: 

1 . Exception Report 

This report presents exceptional events (shortages 
or unused inventory) which should be reviewed by someone. 

2 . Inability to Meet Production Schedule 

It may happen that the production schedule was 
determined without checking its feasibility. If so, the 
schedule is impossible to follow because of shortages/ long 
lead times. 

3. Inquiries 

These can be helpful to the production scheduler to 
prevent events which will later appear as an inability to 
meet schedules. Direct access to the system files using the 
MRP algorithm may help the scheduler to decide if inclusion 
of a production order in a certain period is feasible or not. 

The specific outputs should be tailored to the needs of 
the specific users and the capabilities of the system on 
which MRP will run. 
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E. MRP AND CONVENTIONAL INVENTORY CONTROL 



There are many good reasons for holding inventories. In 
a manufacturing environment the most important reason is to 
prevent production shutdown and allow smooth operations. 

Various techniques were developed to control inventories in 
order to optimize (by minimizing total costs) operations of 
the whole system. 

Among the most famous "conventional" inventory control 
methods are the following: 

1 . Perpetual (Continuous Review) System 

Two inventory levels (RO = reorder objective, ROP = 
reorder point) are determined for each item. Inventory status 
is reviewed with each transaction and when inventory reached 
the ROP level a fixed quantity (RO - ROP) is ordered. 

2 . Two-Bin Inventory System 

This is a simplified continuous review system. The 
ROP is the quantity held in one bin and the RO is the quantity 
in two bins. When one bin runs out of stock, the quantity to 
fill it is ordered. 

3 . Periodic Review 

This system reviews inventory status at fixed inter- 
vals of time. Upon review, an order is placed for the quantity 
required to bring inventory to RO. 

4 . Optional Replenishment 

This is also a periodic review system, except that 
an order will be placed only if inventory is less than a pre- 
determined quantity (ROP). 
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All those policies use the basic "EOQ model" with 
appropriate adjustments of its assumptions to real life. 

After selecting the model, the required data is found (or 
decided upon by a "rule-of-thumb") and used to determine the 
"order quantity," the "reorder point" and "reorder objective." 
Since the models are used to determine "what, how much, and 
when" to buy in the present and for future use, all of those 
techniques have to use forecasting methods to estimate future 
demand and that forecast (based on past demand) becomes the 
basis for all future operations. 

On the other hand, MRP uses the production schedule which, 
of course, provides a sound basis for the computations and 
promises smaller deviations from the plan to actual performance. 

That advantage also has a price. In order to be' able to 
operate an MRP system, a production schedule is needed in 
advance and, for each product, the system has to have an accur- 
ate bill of materials. This is not the case with the other 
techniques. Since they do not depend on a specific production 
plan, they have no need whatsoever for the master schedule or 
bill of materials. All that is needed is past demand trans- 
lated to a forecast which helps to determine all inventory 
levels . 

Another major difference lies in the behavior of the 
systems in an environment of changing products. In such a 
case, conventional methods may cause a build-up of "dead- 
stocks" and shortages in the required new items, whereas MRP 
will "sense" that in advance and stop ordering the items not 



29 



needed and prepare the required materials. Because of those 
changes, traditional techniques also suggest higher safety 
stocks . 

Generally speaking, MRP will be more responsive to pro- 
duction because of the fact that it uses the same plan and 
objective- -the production schedule. This is not so with the 
traditional methods which do not consider it at all. 

In summary, when comparing MRP to other conventional 
production and inventory control systems, one can identify 
the following advantages and disadvantages :- 



ADVANTAGES 

1. Based on production 
schedule 

2. Allows small or no 
safety stocks 

3. Responsive to changes 
in demand 

4. Easily identifies 
"excess” items 

5. Does not have to 
keep historical data 



DISADVANTAGES 

1. Requires a production 
schedule 

2. Requires a large, high 
quality data base 

3. More complex, more 
difficult to use 

4. More difficult to 
implement 



This comparison shows that MRP has advantages as well as 
disadvantages. Before a decision is made to implement it, 
all factors have to be considered to determine that the 
investment (money and effort) is worthwhile. 

F. IMPLEMENTING AN MRP SYSTEM 

Before addressing the specific problem of implementing an 

MRP system, a few words should be said about implementation 

of an ADP (Automated Data Processing) system in general. 
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The process of implementation usually begins with the 
very first idea about system change and it terminates when 
the system has been successfully integrated with the opera- 
tions of the organization. This process involves the study 
of the new desired application, determination of the objec- 
tives, participation of the future users in the design of 
the "new” system and selection of the steps and timetable 
to change the system from its present configuration to the 
desired one. 

In this specific case, the steps which will be addressed 
are the initial study prior to the decision to proceed to 
actual implementation, the various considerations which 
should be discussed in that analysis, and the basic steps 
towards implementation. 

The first problem that should be addressed is whether 
the system is mature enough for MRP. The problem is not one 
of satisfying prerequisites, but whether the change to MRP 
is too big for the organization. Nolan and Gibson [3] iden- 
tify four stages in the growth of EDP systems in terms of 
the applications, EDP personnel, and formal management tech- 
niques applied to each. The four stages are:- 

1. Introduction of simple applications (such as payroll 
and accounting) . 

2. Specialization to develop a variety of applications. 

3. Moratorium on new applications and emphasis on control. 

4. Specialization for data-base technology and tele- 
process ing . 

Each succeeding stage requires more skills, more sophisticated 
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techniques, and a more mature environment than its predeces- 
sors. In order to proceed to a higher stage, there should 
be experience with lower- stage applications which naturally 
form the basis for evolution. In the case of MRP it will be 
obvious that the organization should have previous experience 
in developing and using at least separate systems for produc- 
tion and inventory control. At this point, the problem will 
involve "only” their integration and not the much more compli- 
cated problem of creating and integrating an advanced system. 

Given the environment, the existence of fundamental skills 
and the acceptance of the decision and its justification, the 
following actions are to be taken: 

1. Analyze available and required input for MRP. 

2. Design the new MRP system. 

3. Identify required changes in existing data files and 
their relations to other applications. 

4. Determine specific output from the MRP system. 

5. Identify required changes to existing software and 
development of new programs. 

6. Develop or buy software: "make or buyl' 

7. Prepare a plan of how to switch from one system to 
the other. 

8. Train personnel. 

9. Prepare a timetable for carrying out those actions. 

10. Carry out that plan. 

The first problem that comes up after knowing what to do 
is deciding who will do it. It is possible to assign the job 
to either an outside consultant or to the organic EDP department. 
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Although, bringing in an expert may sometimes cause troubles 
(especially dissatisfaction of in-house personnel) , this 
might be a good solution. On the other hand, using the 
organization's people develops their skills, makes use of 
their familiarity with the system and prevents the problem 
of later being left to maintain a system which was developed 
by outsiders. 

Another problem is that of designing the new system. It 
is desirable to have the users participate in that process 
and contribute their knowledge of existing problems and sug- 
gestions for system improvement. A steering committee , 
composed of users and EDP people, can serve as the body to 
gather essential information about the old and new systems. 

Two other problems are interrelated. These are the 
problems of changing existing software and developing new 
programs. There are MRP software packages. However, the 
problem with these software packages is that they were not 
designed for the specific user that is going to use the 
system, and since the software package is not flexible, it 
will require changes; this, of course, should be avoided. 

The same rationale should also be used to avoid unnecessary 
expansions. The developers should concentrate on the minimum 
expansion and changes required to accomplish the objective 
but avoid making them too restrictive and inflexible with 
respect to later developments. 

An important factor in the development of the new system 
is planning the process of switching from using the old system 
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to the new one. It is highly desirable not to implement all 
changes at one time. It would be better to first change the 
structure of the data files and to continue using old programs 
(although that also requires minor changes) , then: 

1. Use converted data files to develop and test new 
software . 

2. Run old and new systems in parallel. Compare test 
files and outputs with current system. 

3. After new software is error-free, stop using the old 
system and transfer to the new one. 

This sequence allows better testing and smooth switching 
without having to cope with many problems ("bugs," human 
resistance, lack of experience) in a short and crucial period 
of time. 

Another decision that must be made concerns which version 
of MRP to choose: "net change" or "regenerative" system. The 
final output is going to be the same, but the EDP problems 
encountered in the net change system are much more complicated. 
It requires keeping old schedules and their back-up files, 
generation of new files for the updated production schedule 
and, finally, their comparison. In addition to the fact that 
this data processing is more complex, special attention is 
also required any time changes are made to files or programs. 
This makes the system more sensitive to "bugs"--a highly 
undesirable state of affairs. 

Another subject which should be analyzed at this time is 
the introduction of advanced data base management systems. 
Traditional information management is based on keeping many 
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dedicated files of data related to specific subjects such as 
inventory status, finance, production schedules, statistical 
files or personnel records. That concept simplifies manag- 
ing each individual subject but creates duplications in 
information reported and held, which usually results in 
conflicts. On the other hand, the new concept is to have 
one comprehensive data-base holding all interrelated data. 
There are special software packages which support mainten- 
ance of data bases (IMS, IDMS, TOTAL, ADABAS and others) and 
using them may help to create a sound basis for a good MIS 
(Management Information System) . The planning period before 
transition to MRP is a very good time to investigate the 
possibility of moving to one central data base. The reason 
is that MRP needs well coordinated files of inventory status, 
production schedules and bills of materials. 

As mentioned earlier, the MRP system needs very accurate 
and consistent files requiring a very careful processing of 
data (especially the BOM) before operations begin. Since a 
similar process is required when converting to a modern 
data-base, it is recommended to combine both into one step 
and make sure that the conversion is done carefully and 
completely. 

A very important factor which must be kept in mind dur- 
ing the whole process is the human factor. Implementation 
of an MRP system is going to affect the users of the system 
(inventory managers, production managers and other functions) 
and the ones who are responsible for implementation (EDP 
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and others). Those people must be involved in the process, 
asked to contribute, be trained in system operations and 
be made to feel a part of the system. The system may require 
changes in working habits and procedures and their coopera- 
tion is essential for success. 

G. CONCLUSIONS 

The discussion so far has addressed a pure MRP system. 

But does it exist in a real life situation? Pure MRP is 
unlikely in a real situation. There are only a few organi- 
zations where the MRP system will be able to cover all 
materials used. Since the others must also be managed 
somehow, a compromise must be found between traditional 
methods and this one. That combination is necessary espe- 
cially in organizations whose work is not pure production, 
even though the work may be of a repetitive nature. This 
can be the case of a shipyard or a repair facility which 
also produces some items. 

The nature of repairs is that there is not an accurate 
"Bill of Materials" for repair of a given item, although 
averages and standard deviations may help represent the case 
as "pseudo-production." This is particularly true about 
inexpensive spare parts (bolts, nuts, fuses or other "con- 
sumables") which have a high total demand, but also high 
deviations in requirements for repair of certain items. 

The best way to act in such an environment is to combine 
MRP with the regular EOQ models. This will require classifi- 
cation of items according to the system which is used to 
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control them. Items which are inexpensive and "high-movers" 
can be controlled by the simple EOQ model, whereas more 
expensive items, which are not common to many systems and 
have low discrete) demand, can be treated by the MRP 

system. 

It may appear that this combination is more complicated, 
but it turns out that the input required for MRP already 
provides the input for the simple EOQ model and the overhead 
from having another module is overridden by the extra benefits 
that the combination gives. 
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III. SUPPLY SUPPORT OF NARF ALAMEDA 



The intent of this chapter is to describe the "present" 
supply support of NARF Alameda, the concept that underlies 
this system, the data-base and computer resources used in 
this process, the weak points of the system and elements that 
require improvement. 

Phase II of the San Francisco bay area SER is now underway 
and it is somewhat difficult, however, to be exact in this 
description of the "present" system because of the consolida- 
tion and the continual changes resulting from it. There will 
be an attempt to distinguish between activities which existed 
prior to consolidation and those resulting from consolidation. 
If everything goes according to the original schedule [7:19], 
the present system with temporary, pre-NISTARS improvements, 
will last throughout April 1981. 

Figure 4 depicts both pre and post consolidation requisi- 
tion channels of NARF Alameda and provides a framework for 
the description to follow. 

A. CONCEPT AND OPERATION 

The concept applied for the supply support of NARF Alameda 
is the Area Support Concept [9:111-15]. This concept is gen- 
erally employed in geographical areas surrounding NSC's and 
NSD's where the customer activities are nearby. According to 
this concept, the customer--in this case the NARF--does not 
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After Consolidation 
Before Consolidation 



Figure 4: NARF's pre/post consolidation requisition 

flow 
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stock items [9] --except nonstandard items or expense item 
material -- and whenever items are needed they have to be 
requisitioned through the requisitioning channels. 

1 . Pre-Consolidation Support 

Prior to the consolidation, the NARF shops had three 
sources of supply: 

a. The NARF’s NIF (Navy Industrial Fund) Stores. 

b. NAS Alameda--£or aviation items. 

c. NSC Oakland--£or other items. 

Each of these sources has different stocking policies and 
procedures to determine the items to stock, order quantities, 
and reorder points. 

a. NIF Stores Items 

Items stored in the NARF’s storerooms are deter- 
mined by the NARF ' s material planning personnel. However, 
approval for establishing items in the Alameda stores is 
restricted to material section heads or higher. The material 
planners are allowed to establish NIF stores items with mini- 
mum demand frequency of six per quarter and maximum unit price 
of $25. Order and reorder quantities are determined by the 
material planner using his experience and the technical data 
(drawings) available. 

A major portion of the material support for the 
industrial operation is provided by the Pre -Expended- Bin 
(PEB) operation. It contains high usage, low-priced items 
that have been expended from stock records and charged to 
overhead at the NARF. The NARF also maintains physical 
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records of materials provided by customers for use on their 
own jobs. 

The NIF Store operation is basically a manual 
operation. As a result, there is not any (recorded) historical 
demand data to be used for more intelligent demand forecasting 
or inventory control. This is going to change with the intro- 
duction of the Naval Air Industrial Material Management System 
(NIMMS) that will be described later on. 
b, NAS Alameda 

Before the consolidation, NAS Alameda supported 
the NARF as a wholesale customer for IR Cog material and as 
a retail customer for the 9 Cog and SPCC managed items. The 
wholesale stock levels were maintained by ASO. Unfilled 
NARF requirements were transmitted to ASO for referral, pro- 
curement or other action as required. 

On the other hand, the NARF's demand for retail 
material was provided for by the VOSL (Variable Operating and 
Safety Level) model. The disadvantage of VOSL in this case 
is that it uses historical demand to forecast future require- 
ments. In reality, NARF demand is dependent on the production 
schedule of the NARF. For example, during the second quarter 
of FY '79 the Point of Entry CPOE) supply effectiveness (i.e., 
the ratio of requisitions that were filled and the total number 
of requisitions entered into the system) of NAS Alameda was 
53.2 percent for IR Cog expense items, 74.4 percent for 9 Cog 
items and 55.7 percent for SPCC managed items [21]. These low 
figures appear to be a result of the model discrepancy, as 
described above. 
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c. NSC Oakland 



NSC Oakland was NARF Alameda's source o£ supply 
for the 9C , 9D, 9G, 9N and 9Z Cogs. NSC Oakland is a Special 
ized Support Depot (SSD) ; that is, an activity with a special 
ized mission as to the type of material or scope of support. 
Its stock replenishment is centrally controlled by the 
cognizant Defense Logistic Agency (DLA) Item Manager (IM) . 
Stock replenishment is based on historical demand. 

Similar to the situation at NAS Alameda, this 
policy does not seem to fit the case. 

2 . Post-Consolidation Support 

Phase II of the consolidation (administrative consol- 
idation) is currently being implemented after phase I (plan- 
ning) has been completed. Its most significant effect is the 
fact that NAS Alameda no longer supports the NARF, and the 
only external source of supply is now NSC Oakland. It also 
becomes the replenishment source for the NIF Stores inventory 
As mentioned earlier, this period is an intermediate 
period that will last until the installation and integration 
of the NISTARS at NSC Oakland and ASKARS at NARF Alameda, 
a. NIF Stores 

The consolidation has no direct effect on the NIF 
Stores except that their stock replenishment will be now only 
from NSC Oakland (NSCO) and not from NSCO and NARF Alameda. 
However, the implementation of NIMMS requires the appropriate 
interfaces to NISTARS and ASKARS so that savings from the 
improved control and usage of recorded data would not be 
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degraded by additional work (caused by old processes) when 
items are replenished, stocked or retrieved. 

The NIMMS software package is designed to process 
inventory transactions and does this through an Inventory 
Balance File and a Transaction file. Those files are used 
to produce management reports, especially the "NIF Retail 
Store Stratification” report in which reorder levels are 
updated, and the "Automatic Replenishment"- -which uses those 
levels and the on-hand quantity. 

The function of automatic replenishment requires 
an interface to ASKARS and NISTARS, to obtain information on 
the requisitions’ status in order to determine when replenish 
ment is required, and later, to direct the material for stock 
ing in ASKARS. 

b. NSC Oakland 

The change in the organizational structure by 
itself would not improve the availability of items required 
by the NARF. In fact, there are many items that were not 
carried by NSC Oakland before the consolidation and will have 
to be carried afterwards. 

Items for the NARF will be separated from the 
regular NSC stock Csometimes physically and sometimes only 
logically) into a Ready Supply Store (RSS) . The range and 
depth of the RSS stock will eventually trade the actual de- 
mand instead of forecasting demand only according to histor- 
ical demand. The actual demand will be forecasted by the MRP 
model using the BOM information and the production schedule. 
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The implementation of RSS and MRP concepts will 
take place in three phases 

1. Establishing the RSS and its initial stock levels, as 
described below. 

2. Change RSS operation to level settings by "temporary” 
MRP. 

3. Approval, implementation and operation with the pro- 
posed MRP system. 

Since the temporary MRP data base and software 
were not ready on 11 November 1979 (the day of establishing 
the RSS) a "rule of thumb" was used [19] to determine the 
initial RSS stock. The procedure to set those levels was 
as follows; - 

1. Identify all customer orders that will be worked in 
FY '80. 

2. Generate a list of "candidate" NIIN'sby searching the 
NARF ' s POE demand for those customer orders in the 
last three quarters. 

3. Delete from the list any NIIN that does not belong 
to one of the following Cogs: 9Z, 9N, 9G, 9D, 9C. 

4. Add items for the following four special support 

programs: F62 engine, TF34 engine, 50K-17 engine and 

A6E aircraft. 

5. For all items in that list, compute the NAS Alameda 
protected quantity (stock to support the NARF and 
squadrons for one quarter, computed by VOSL) . 

6. Split the protected quantity: 85 percent for NARF and 
15 percent for retail protected quantity. These 
percentages were determined by the share of the NARF’s 
requisitions out of all requisitions filled by NASA. 

7. Compute the initial RSS quantity for the item as the 
maximum of 0 and the difference between the NAS Alameda 
on -hand balance and the retail protected quantity. 

8. Write an AOA ("fill or kill") requisition automatically 
for all items with a positive initial RSS quantity (for 
that quantity) . 
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The reasons for using that simple procedure were 
mainly the short time available and the "need" to prevent its 
decapitalization to DLA owned stock at NSCO. It also saved 
a lot of time by generating the requisitions by software and 
not manually. 

The introduction of the RSS required changes in 
the NARF's requisitioning procedure to NSC. Instead of merely 
submitting a requisition to NSC, the NARF now has to first 
determine if the item is available from the RSS stock. If 
so, the requisition will be directed to the RSS; otherwise, 
it will be referred directly to NSCO wholesale stock. A 
terminal communication network allows on-line inquiries 
against both RSS and wholesale stock. 

The integration of the temporary MRP system will 
occur gradually as that software and data base are expanded. 

The requirements for the second quarter of FY80, generated 
by MRP, will cover only the F/E and engine programs. The 
requirements for the other programs will be determined manually 
and added to those generated by MRP. Afterwards, the require- 
ments for the third quarter of FY80 will be generated by MRP 
for all programs. These requirements will be checked and 
updated manually by the material planners before submission 
to NSC Oakland. 

The process of determining and submitting require- 
ments to NSCO can be further improved with the implementation 
of the proposed MRP system. 
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B. AUTOMATED DATA PROCESSING OVERVIEW 



As described earlier, prior to the consolidation both 
NSC Oakland and NAS Alameda were involved in supply support 
o£ NARF Alameda. One of the implications of having two 
"suppliers" was that both activities had to carry out similar 
inventory management functions, i.e., both activities had to 
process separately the same kind of transactions and maintain 
the same kind of files, both referring to the same customer-- 
NARF Alameda. Both NSC Oakland and NAS Alameda use the same 
inventory management system: the Uniform Automated Data Pro- 
cessing Sys tern- - Stock Point [UADPS-SP]. After the consoli- 
dation, NSC Oakland becomes the only direct supplier for the 
NARF. 

With respect to data processing, it means that NSCO's 
data processing department will do most of the data processing 
of data relating to the NARF. However, in addition to pro- 
cessing done by NSCO, there will be some inventory management 
data processing by the NARF itself. This may involve running the 
MRP application and generating the requirements to be sub- 
mitted to the NSCO. 

This section describes NSC Oakland's data processing 
systems. Details on data processing and DP equipment at NARF 
Alameda are given in the chapter describing the temporary 
MRP application. 

1 . Data Processing Equipment and Applications 
at NSC Oakland 

NSC Oakland is one of several of the Navy activities 
using the Uniform Automated Data Processing System- - Stock 
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point (UADPS-SP) . UADPS-SP is the standard software package 
used by Navy stock points to carry out the various inventory 
management functions. However, inventory control is only one 
of the applications run by NSCO's Data Processing Department 
(DPD) as UADPS-SP. The major applications are the following 
ones : - 

1. Inventory Control. 

2. Requisition Control. 

3. Financial Inventory Control. 

4. Stores Accounting. 

5. Civilian Employees Payroll. 

6. Supply Overhaul Assistance Program. 

7. Labor/Cost/Allotment Accounting. 

8. Procurement and Procurement Accounting. 

The list of applications is so long mainly because 
UADPS-SP was developed during the early 1960 's, and although 
it underwent several improvements and modifications, the 
system is still using concepts and equipment from that period. 
As a result, instead of having one integrated system, the 
"system” is composed of a set of related applications that 
use many traditional files (as opposed to an integrated data- 
base and a data-base management system), many old-fashioned 
programs and processing runs and a variety of data processing 
equipment. Appendix A gives a list of selected UADPS-SP files 
which, as mentioned earlier, are only part of the data-base. 

In addition to the above list of applications, the 
DPD runs also a telecommunication system. The network has 
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terminals in the San Francisco bay area and at other Navy 
facilities, and provides inquiry services relating to inven- 
tory and requisitions and data-entry for material storage/ 
receiving and for procurement. 

The hardware consists mainly of a dual system: a 

Burroughs B-4800 CPU and a Burroughs B-3500, a peripheral 
switching unit that helps sharing the peripheral devices by 
both CPU's and thereby improve their utilization. The 
B-3500 is used with a front-end processor (Burroughs B-874) 
for communication, whereas the B-4800 handles the batch- 
processing applications. The non- inventory control applica- 
tions are handled by a Honeywell H200 computer, a Wang 
computer and an IBM 360/20 card-system. Most of the termin- 
als used in the communication network are Burroughs products 
(TD-800, TD-700, TC-500). Until recently some non-Burroughs 
terminals were also connected to the network (Zentec and 
Hazeltine) . The system also includes three line printers, 
two card readers, two card-punchers and a variety of conven- 
tional equipment. 

The DPD operates in three shifts, seven days a week 
and, according to the DPD director, the equipment is utilized 
to 90 percent or more of its capacity. The major implication 
of this fact is that it is very difficult to add new applica- 
tions to the system and also that equipment failures can 
generate severe backlogs in the system. 

Another import aspect of the operation of the DPD 
is that it usually does not develop its own software. 
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Only applications that are simple and local in nature are 
written by local programmers. 

2 . The Inventory Management Subsystem 

The UADPS for stock points is divided into three 
subsystems, each consisting of one or more applications and 
each serving a logical group of stock point functions. The 
three subsystems are:- 

1. Activity Management (Designator A). 

2. Inventory Management (Designator I). 

3. Data Processing Environment (Designator D) . 

The highest level of interface between the functions 
performed at a stock point and the UADP System is at the 
application level. In UADPS terminology, the term "appli- 
cation” is arbitrarily used to define those data processing 
actions which supplement the manual actions necessary to 
carry out a given function. Consequently, what is usually 
referred to (not in UADPS) as inventory management (applica- 
tion) is in UADPS terminology a subsystem and is composed of 
several applications. 

Each application is subdivided into a variable number 
of operations which are defined as one or more ADP runs per- 
formed to produce a given major product or result, e.g., 
produce a given report, process a specific type of transaction," 
etc. The large numbers of applications and operations, and 
the fact that those operations are scheduled manually, explain 
why it is so difficult to run the system. 
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The following applications comprise the inventory- 
management subsystem: 

1. Customer Information (designator lA) involves the 
actions required to provide information of any nature 
to customer activities. 

2. Receipt/Due (designator IB) involves those actions 
beginning with the establishment of a due- in through 
receipt of proof of storage. 

3. Issue/Demand Processing (designator IC) begins with 
the receipt of demand document and continues through 
the preparation of a referral order or issue document/ 
picking ticket and proof of issue. 

4. Inventory Control (designator ID) includes manipulation 
of demand data to set stock levels, determining replen- 
ishment requirements, reconciling replenishment back 
order requests, and processing replenishment documents. 

5. Quality Control (designator II) involves stock record 
accuracy, including location audit, physical inventory 
and physical inspection of stock. 

6. Disposal (designator IM) involves computation of excess 
quantities and follow-up on disposal and/or shipment 

of excesses. 

7. Automated Ready Supply Stores System (designator IN) 
involves the supply and financial management and 
recordkeeping functions for RSS. NARF Alameda's MRP 
system will have to interface with this application. 

8. Records Maintenance (designator IP) involves those 
actions , necessary to maintain accurate mechanized 
records . 

9. Repairables Management (designator IR) involves the 
actions necessary to induct NRFI (Not Ready for Issue) 
material into a repair facility and to maintain 
control throughout the repair cycle. 

3. Data Files 



The inventory management subsystem uses and updates 

most of the files in the data base. Of special importance 

are the Master Stock Item Record (MSIR) file and the files 

which contain customers' requisitions: the Requisition Status 

File (RSF) and Demand History File (DHF) . 
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The MSIR is a variable length, direct access record 
containing stock status data for each item carried in stock 
at the activity. Data elements relevant to identification, 
control, storage, and quantities of the item are stored in 
a header record. As stock data accumulates (demand history, 
demand frequency, due- in quantities and others), it is added 
in the form of trailers. The access key to the MSIR is by 
Federal Item Identification Number (FIIN). 

The RSF contains randomly stored records of customers' 
requisitions (stored and accessed by document number) and of 
the supply action that has been taken by the stock point to 
satisfy the requisitions. The RSF covers the most recent 
three months. 

The DHF contains the same kind of information as 
the RSF but covers the previous six months. Records that 
are deleted from the RSF are transferred to the DHF. 

The various operations that comprise the inventory 
management subsystem are run on various frequencies from 
daily runs to weekly, monthly, quarterly and annual runs. 

The files are updated on a daily basis although certain up- 
dates occur less frequently. An important disadvantage in 
the design and in the way the system is run is the fact that 
many different programs (operations) update the same files. 
This makes it very difficult to control the system, to ensure 
the correct sequence of file updates and, especially, to re- 
produce a previous state of the system files in case of a bad 
file entry or detection of a software error after the faulty 
program was used for a while. 
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4. UADPS and MRP 



From the discussion thus far, it should be clear 
that UADPS and the MRP applications have two different spon- 
sors. UADPS is run by NSC Oakland whereas NARF Alameda will 
develop and benefit from implementation of MRP. However, 
since vital information is available at NSC Oakland's DPD 
and since it will do the computerized inventory management of 
the inventory reserved for the NARF (in the RSS's), it is 
necessary to establish an appropriate interface between the 
systems . 

The areas in which the UADPS and MRP systems need 
coordination and/or use the same data are: 

a. Inventory Status File 

MRP needs an inventory status file for determin- 
ing requirements and for other data elements on each item 
(such as lead time). This information is contained and up- 
dated in the MSIR. 

b. Bill of Materials 

Since maintenance work involves variable quanti- 
ties of components for doing the same work, the bill of 
material file of an MRP system has to be created and updated 
according to historical usage rates of components, when 
doing specific jobs. Computing usage rates involves identi- 
fication of the quantity of items that were repaired/produced 
on a specific job order, and the components that were required 
to accomplish the job. The first piece of data is available 
at the NARF whereas usage information is contained in the 

requisition files--both RSF and DHF. 
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c. RSS Stock Levels 



One of UADPS's functions is to set and update 
stock levels for RSS. UADPS uses the historical demand as 
the basic data for setting those levels. It will be necessary 
to override the "regular” level settings by the requirements 
generated by MRP. 

These problems will be further addressed in the 
next chapter. 

C. EVALUATION AND CONCLUSIONS 

The Area Support Concept employed in support of NARF 
Alameda provides a significant advantage because of the cen- 
tralized management, stocking and procurement of supplies 
("economics of scale"). However, the common method applied 
to forecast demand may have an adverse effect on the effec- 
tiveness of supporting the NARF. The VOSL model assumes that 
demand in the future will behave the same as in the past but 
that may not be the case for the NARF because its material 
requirements are driven by a production schedule which varies 
from one quarter to another. This problem can best be solved 
by employing the MRP model. 

The NIF store's inventory is and will continue to be 
managed by a totally different system. The fact that the 
items carried in the NIF stores are fast moving, low cost 
items seems to suggest their exclusion from the MRP system 
at least at the beginning. Also, the fact that their demand 
is more stable justifies the use of a conventional model. 
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However, the time may come when the MRP system will be suffi- 
ciently reliable, when it may be more cost effective to have 
only one system for managing the NARF's material requirements. 
Including this inventory in the MRP system will require adding 
these items to the BOM file. 

As to ADP, it seems that NSCO's DPD may not be the activity 
to run the MRP application. The out-dated equipment and the 
large variety of applications that are presently run seem to 
be sufficiently complicated to manage so that perhaps the NARF 
should run the MRP system and provide the end results- -namely , 
the material requirements and RSS stock levels, to NSCO's DPD. 
However, possible incompatibility of the Burroughs equipment 
at NSC with the NARF system may require appropriate transfor- 
mations of data to allow use of information maintained by 
NSCO (MSIR information and recognition data) in the NARF 
system. 



54 



IV. THE TEMPORARY MRP APPLICATION ^ 

When the idea to implement MRP at NARF Alameda was 
proposed, it seemed that before doing the full-detail design 
of the application it would be appropriate to carry out an 
experiment in which the MRP technique would illustrate the 
extent to which it could actually forecast the NARF's mater- 
ial requirements. But, as people got more involved in the 
subject and obtained a better understanding of the work 
involved, the 500 Department (the department in charge of 
this application) decided to redefine the objective to design 
the implementation of a s imple MRP system that would take a 
short time to implement, would be capable of demonstrating 
the technique for the purpose of comparison with the present 
system and would provide operational generation of NARF's 
material requirements until ASKARS and NISTARS are installed. 

It was realized that there is a trade-off between sim- 
plicity, required effort and the length of the implementation 
period, and the quality of the results. Unfortunately, the 
NARF's regular personnel had to carry out the project with 
almost no additional people (their mission does not include 
software development!); the short time available made all 
other alternatives infeasible. It is believed, however, 

^Based on personal interviews and discussions with 
LCDR W. P. Benefiel, from NARF Alameda. 
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that even this "low quality" product will produce a supply 
, effectiveness better than that of the present system. 

This chapter describes the "temporary" MRP application, 
j the functions it performs, the data-base and software modules, 
the creation of the initial data-base and the interface to 
j UADPS and NSC Oakland. 

A. SYSTEM OVERVIEW 

The temporary MRP application was developed and is run 
on the ADP system of the production planning and control 
department (500) at NARF Alameda. The system consists of 
a POP 11/70 CPU with an IAS (Interactive Application System) 
general purpose operating system, 512 KB memory, 2 RP06 300 
MB disk drives, 1 RS04 swapping disk, 2 TE16 tape drives, 

1 LPU line printer, 1 CRU card reader, 28 hard wired termin- 
als and some other "dial-up" terminals. This system is used 
to run several local NARF applications and can easily handle 
the MRP application. 

The major objective of implementing the temporary MRP 
system is to generate a forecast of the NARF's quarterly 
material requirements. These requirements are to be used 
as stock levels for the RSS. 

Secondary objectives are to provide the NARF's material 
planners with accurate data that will assist them in doing 
their job, especially when ordering materials for unscheduled 
jobs. The system is also to provide some exception reports 
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on consumption of materials to allow analysis of these jobs 
and the reason for the exceptional consumption. 

The system produces three major outputs: 

1 . Material Requirements 

These are only recommendations. They are checked 
and updated by the material planners if they do not agree 
with the systems recommendations. 

2 . Answers to Queries 

The system provides a set of queries on the BOM file 
and the gross requirements forecast. This information is 
used routinely by the material planners. 

3 . Bill of Material Listing 

The listing is designed to provide the same basic 
information as the queries but requires the material planner 
to do the material requirements computation manually. The 
report is used as a back-up to the communications network 
and also for those material planners that do not have a 
terminal . 

The inputs to the system consist of requisitioning data 
from UADPS and induction data (quantities of items repaired) 
from NARDAC (Navy Regional Data Automation Center) that are 
used to update the BOM file and the workload schedule from 
ASO which is later used to translate the schedule into re- 
quirements. Another input is the information that relates 
lie's (Item Identification Codes) to FIC's (Family Identi- 
fication Codes) which is required for translation of the 
workload schedule- -which is by FIC's- -into a schedule 
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by lie's. The inputs to the system are all external data 
although it is originated by or refers to the NARF. 

A major element that is missing in this MRP application 
is the inventory status file which has to be used for deter- 
mination of net requirements. The reason for that is that 
this application is used only to determine gross requirements 
which are needed as RSS stock levels. Therefore the computa- 
tion of net requirements does not have to take place in this 
system but rather in UADPS-SP. 

The environment in which MRP is run includes both time- 
sharing and batch processing. The requirements generation 
is run on a quarterly basis. The run includes first an 
update of the files and later the generation of the outputs. 
This fact raises some questions about the need for on-line 
inquiries. But it turns out that, since the equipment was 
already there and was underutilized, it would be nice to 
provide this service. 

Figure 5 describes the information network and the 
operation of the MRP application. 

B. MRP DATA-BASE 

The data-base for the MRP application consists of three 
master files and two index files: 

1. The bill of materials file CBOM) (0SI19.DAT). 

2. The workload schedule file COSI20.DAT). 

3. The MRP forecast file (0SI21.DAT). 
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Figure 5; MRP information network diagram 








4. The ”BOM” index (0SI18.DAT). 

5. Index to MRP forecast. 



The BOM file contains information about items required 
to repair end-items. The file is a direct access file 
(access key is the IIC of the end-item) and contains one 
header record and several data records for each end- item 
(IIC). Both header and data records have fixed lengths. 
The header contains information about the end- item and 
summary data about the consumable items required for its 
repair, total cost of consumables for repair of one IIC 
and the total number of the end- items that were inducted 
in the past. 

The data record (one for. each consumable per end- item) 
contains the information as described in Table I. 

Figure 6 describes the header layout. 



IIC 


0 


FIC 


NSN 


COG 


Total Cost 


IIC Induction Qty 


1-4 


5 


6-9 


10-22 


23-24 


25-28 


29-32 



Figure 6: BOM header-record layout 



Access to the file is based on a pointer to the begin- 
ning of the header, read from the BOM index file. The header 
is used, and then (data) records are read sequentially. The 
first character is checked and if it is other than "1" it 
is assumed that the end of the IIC has been reached. 
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TABLE I 



The Data Record 



Columns 


Description 


Data Type 


Comments 


1 


Filler 




Char. 


Decimal Digit 1 


2-14 


NSN 




Char. 




15-16 


COG 




Char . 




17-18 


U/I 




Char . 




19-20 


Planner 8 
Estimator Code 




Char. 




21-24 


Qty (total) 




Integer 


Required for Qty in 
header 


25-28 


Unit price 




Real 




29-32 


# of reqn’s 




Integer 


Whose total Qty is 
in 21-24 


33-36 


Qty per unit* 




Integer 


Max. Qty per 1 end 
item 


i 37-38 


U/I of Qty per 




Char . 


In case it differs 


j 

s 


unit* 






from that in 17-18 


! 39-40 


Essentiality* 




Char . 


"KE” or "NE” 


41-44 


Replacement factor* 


Real 




45-48 


Qty (Qtr 1) 




Integer 




49-52 


# of reqn’s (Qtr 


1) 


Integer 




53-56 


Qty (Qtr 2) 




Integer 




57-60 


# of reqn’s (Qtr 


2) 


Integer 




61-64 


Qty (Qtr 3) 




Integer 




65-68 


# of reqn*s (Qtr 


3) 


Integer 




69-72 


Qty (Qtr 4) 




Integer 




73-76 


# of reqn’s (Qtr 


4) 


Integer 





*The data is extracted from the Weapons Systems File (WSF) 
maintained by ASO. 



61 



The information for each IIC contains data from the most 
recent four quarters. The totals are kept, and an average 
(total quantity/quantity inducted) is computed in specific 
application programs. 

The workload schedule file is a sequential fixed length 
record file, created especially for the MRP application. 

It is created by typing in (using an interactive data entry 
program) the workload schedule received from ASO. The 
schedule is by FIC (Family Identification Code) , as opposed 
to the BOM file which is by IIC. Figure 7 describes the 
layout of a workload schedule record. 



FIC 


NSN of FIC 


Workload Qty 


Standard 


Responsible 


Program 






Scheduled 


Repair Hours 


Shop 




1 - 4 


5 - 17 


18 - 20 


21 - 26 


27 - 30 


41 



Figure 7: Workload schedule record layout 

As seen from Figure 7, the file also contains information 
that is not necessary for MRP- -the standard hours for repair- 
ing the scheduled quantity. Before MRP was initiated, there 
was no other file that contained the production schedule and 
repair standard hours and because it was very useful (for 
other functioners in the NARF) to have them, they were added 
to the records. 

The MRP forecast file contains the consumable NIIN 
forecast for each end item (IIC). These, in fact, are the 
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gross requirements before they are summed to give one quantity 
for each NIIN. This file is used for two main purposes: 

1. Provide data for the material planners for planning 
purposes (answers to queries) . 

2. Record changes made by the material planners to the 
gross requirements generated by MRP. Those gross require- 
ments are subject to inspection, changes, deletions and 
additions made by the material planners, and this file con- 
tains the last (best) version of the requirements forecast. 

The file is a direct access file and consists of fixed 
length records; each record representing a consumable NIIN 
required for a FIC/IIC. The data is grouped in a hierarchical 
order: the highest level is a FIC, then IIC, and then a con- 

sumable NIIN. All data for one FIC is co-located and sub- 
divided into lie’s that comprise that FIC. Within an IIC 
are all consumable NIIN's required for the repair of the IIC. 

Figure 8 describes schematically the structure of the 
file. Figure 9 describes the record layout of the MRP fore- 
cast file. 

The BOM Index file is, as its name specifies, the index 
to the bill of materials file, and in addition, it also 
contains the information that is used as the "translation 
table" of the composition of each FIC by IIC's. This is 
achieved by keeping the total quantity inducted by FIC and 
the specific IIC quantities that comprise that quantity. 
Dividing the IIC quantity by the total (FIC) quantity gives 
the relative frequency of the IIC and allows for the 
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FIC 


lie 


NUN 


NUN 






NUN 












lie 


NUN 














NUN 



Figure 8: Schematic Structure of MRP Forecast File. 



end item-H "Consumables' " data 



FIC 


lie 


NSN 


COG 


U/I 


Forecast 


Extended price 










(F8.2) 


MRP Qty (16) 


per consumable 


1-4 


5-8 


9-21 


22-23 


26 - 33 


34 - 39 


40 10.2) 



NSN 


NSN 


Responsible 


Work 


Program 


Work 


Schedule 


of lie 


of FIC 


Shop 


Standard 




for 


FIC (13) 


50 - 64 


65 - 77 


78 - 81 


82(F6. i;^7 


88 


89 


91 

f 



Figure 9; MRP Forecast File Record Layout. 
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subsequent translation o£ the workload schedule from a FIC 
schedule to an IIC schedule. 

This index file is used by various application programs 
to access the BOM file and its small size allows the whole 
file to be loaded into memory when needed. 

The file contains five different types of records. A 
Type 1 record contains two fields: FIC and the starting 

location of IIC location records within this file. There 
is a single record per FIC and each contains a pointer to 
the location of the corresponding IIC's. 

The Type 1 records are delimited by a Type 2 record 
which simply contains the four characters "END*". 

Following the Type 2 record is a group of Type 3 records 
--one record per FIC, each record containing " 0000 ” in the 
first four characters of the record (an identifier) and then 
the FIC quantity of total inductions and the FIC itself. 

This is the data used for the translation of FIC to IIC's 
and could, in fact, have been stored in the Type 1 records. 

Type 4 records contain the actual pointers to IIC loca- 
tions in the BOM file. Each record contains the IIC, IIC 
induction quantity (for translation), starting BOM location 
and ending BOM location for this IIC. The Type 4 records 
are grouped so that all IIC's belonging to one FIC are 
together, and the starting location of this group is being 
pointed at by a Type 1 record. 

A Type 5 record contains ” 0000 '' and "0000" and marks 
the end of the file. 
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The Index to the MRP Forecast file is a regular index 



file allowing access to the master file by different keys: 
lie, FIG or NSN. 

C . SOFTWARE 

The temporary MRP application consists of the following 
modules ; 

1. File maintenance 

2. Queries 

3. Requirements generation module. 

File maintenance is the set of application and utility 
programs that are used to update the BOM file. As described 
in the previous section, there is no update of the production 
schedule file. 

The principle behind updating the BOM file is to advance 
the information regarding the second, third and fourth quar- 
ters by one quarter forward (thereby deleting the ''oldest” 
quarter), and then insert the information regarding the past 
quarter into the fourth quarter’s location. The file that 
contains the BOM information from the past quarter is created 
independently and is used later as one of the inputs to the 
program that creates the new generation of the BOM file. The 
same process was utilized in creating the initial BOM file. 
All that is necessary is to stop after creating the file with 
the most recent data (on the first run, it is the only data) 
and use the output as "the" BOM file. 
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The steps that comprise the file maintenance process 
are as follows: 

1. Create (by a simple data entry program) a direct 
access file of all customer orders that have been used 
during the last quarter. 

2. Using this file as a table, extract from the Demand 

History File all records that contain customer orders that 
are in the table. (Note: The customer order contains the 

lie.) 

3. Sort these records, which are in fact consumption 
data, by IIC. 

4. Construct the "induction data" file containing for 
each IIC the total quantity inducted during the last quarter 
Sort the output by IIC. 

5. Use the induction data and the consumption data 
(both sorted by IIC) to create the one quarter BOM file. 

The same information is used to update the FIC to IIC "trans 
lation table" that is contained in the BOM file. 

Figure 10 describes the file maintenance run. 

The Queries are programs designed to assist the material 
planners in their work. There are dynamic queries in which 
the planner can change the information in the file he is 
querying as opposed to "static" queries in which the infor- 
mation is only presented. 

The " static " queries include the following: - 

1. Inquire BOM by FIC. This inquiry displays all data 
(with appropriate headings) about the FIC. 
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Figure 10: BOM file maintenance run. 
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2. Inquire BOM by IIC. 

3. Inquire MRP forecast by the following pairs of 
parameters : 

(a) $ value/shop 

(b) $ value/IIC 

(c) $ value/FIC. 

The $ value refers to the value of the consumable items. 
Such a query will list all consumable forecasts for end 
items/shops whose $ value is greater than the threshold 
specified in the query. The information about each end item 
is presented separately. 

4. Inquiry by a variable threshold of $ value of consum- 
ables value. 

Here the planner specifies a value threshold and gets, in 
return, all NSN's whose value is greater than the threshold 
specified. This allows the planner to concentrate on the 
most expensive items first, and then on the other items. 

The ’’ dynamic *' or interactive inquiries refer to the MRP 
forecast file and are intended to use the material planner’s 
knowledge in order to get a ’’better" forecast. The planner 
inquires the file by NSN (of consumables) and thereby gets 
sequential access to all IIC’s that include that consumable. 
After having the information displayed, the planner can (by 
using appropriate codes) make additions, deletions or changes 
in the forecast of the requirements for that specific IIC. 

The Requirements Generation is the heart of the appli- 
cation and concludes the whole process. This phase has two 
separate steps: 
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1. Creation of the MRP forecast. 

2. Creation of the transactions for the RSS stock 
replenishment . 

The MRP forecast is generated by computing an average 
requirement for each IIC (total consumption during four 
quarters divided by total end-item inductions) and then 
multiplying it by the quantity of that IIC scheduled for 
induction during the coming quarter. The IIC induction 
quantity is computed from the FIC schedule by multiplying 
the FIC quantity by the relative frequencies of the IIC's 
composing the FIC. This forecast is used to load the file 
which will be used by the material planners. 

After the material planners have finished their changes, 
the next step is to sort the requirements by NSN (of consum- 
ables), sum them for each NSN and write a transaction to an 
output file; this file contains the NSN and the total 
quantity. This quantity will have to be in the RSS at the 
beginning of the quarter (or shortly after it) to ensure 
smooth operation of the NARF according to the production 
schedule . 

D. INPUT, OUTPUTS AND PROCESSING 

The inputs to the MRP application are mainly the outputs 
of the UADPS-SP. These include the demand history file (DHF) 
from which the NARF’s requisitions are extracted, to be used 
later as consumption data for updating the BOM file, and also 
the MSIR, from which general information such as nomenclatures. 
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units of issue, unit price and quantity-on-hand (at the RSS) 
are extracted. 

Another input is the committed workload file (CWF) which 
contains induction quantities. This file is maintained by 
NARDAC for the independent production control application. 

The workload schedule file that was described in the data- 
base section is, of course, another important input to the 
system. 

The last input is the set of valid customer orders (job 
numbers) which are entered through an interactive data-entry 
program and are used as a table for extracting relevant 
records from the DHF. 

All inputs described above, except the MSIR, are origin- 
ated at the NARF, although part of them (DHF, CWF) finally 
arrive at the MRP application as external inputs. This is 
an important factor because it leaves very little control 
(frequency, data integrity) that can be imposed by the MRP 
application. 

The outputs from the MRP application were also described 
earlier. They include essentially the transactions for level 
setting of RSS stock, answers to queries by the material 
planners and various reports which are generated during the 
process of file maintenance and requirements generation. In 
a well developed system, these reports would have been outputs 
of other applications, but since these do not exist at the 
NARF, this was an opportunity to produce these products. 
Examples of these products are a list of customer orders 
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(instead of a production schedule) , summary induction infor- 
mation by lie, and BOM listings for general use by material 
planners (as back-up to inquiries). 

The MRP application involves two modes of processing. 

The first is the process of file maintenance and require- 
ments generation which is run once per quarter. The other 
is the inquiry system, in which files and programs are loaded 
permanently and used by the material planners. 

The file maintenance involves a sequence of events that 
determines the schedule of the whole process. The first 
constraint is that the BOM cannot be updated as long as 
customer orders are still active because the consumption is 
not complete yet. Customer, orders are closed at the end of 
the second month of the quarter following the quarter for 
which they were opened; this then is the earliest time for 
the beginning of the process. 

A second constraint is imposed by the determination of 
the production schedule. This is done in a conference that 
takes place during the first week of the third month of each 
quarter, and during the conference the schedule for the 
coming quarter is determined and a tentative schedule is 
prepared for the following quarter. 

Consequently, the processing goes as follows: The old 

BOM and the tentative production schedule are used to pre- 
pare the background information for the conference (identify 
critical items required' to carry out the schedule) . Then, 
during the first week of the third month, the file maintenance 
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run is performed making the BOM ready for generation of the 
gross requirements. The requirements generation program is 
run in the second week of the third month using the final 
production schedule that was determined in the conference. 

The MRP forecast is then loaded for analysis by the material 
planners who have another week to make their changes in the 
material forecast. At the end of the third week the final 
run is made and the transactions are generated and submitted 
to NSC Oakland. This leaves at least seven days for NSC 
Oakland to process the transactions and to position the 
materials in the RSS. 

E. EVALUATION OF THE TEMPORARY MRP SYSTEM 

A review of the temporary MRP application reveals a number 
of problems. The first problem relates to the production 
schedule. Implementation of MRP requires the existence of 
such a schedule. The NARF does not have an automated produc- 
tion schedule, and the file that is used here is created 
especially for the MRP run. Consequently, the file is used 
only for MRP and lacks feedback and updates as the schedule 
is carried out. Therefore, the possibility of updating the 
material requirements during the quarter does not exist. 

The file maintenance software also involves some problems. 
The software was designed with simplicity as a goal, thus 
leaving some areas uncovered. One of these is the update of 
the BOM file as new jobs appear. Since the only basis for 
updating the BOM file is actual jobs that have been completed 
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in the past quarter, there is no way to enter information or 
estimates about jobs that are scheduled for the first time. 
This means that the system will not be able to forecast re- 
quirements for the whole production schedule, and there will 
always be some customer orders that will not have materials 
prepared. This problem is partially solved by allowing 
material planners to change forecasts, but they do not have 
the possibility of inserting a whole new item. 

Validity checks on input are another problem that is 
treated only partially. Although most of the inputs come 
from other systems, there still should be some checks, 
especially on the reasonableness of material consumption. 

An analysis of the NARF ' s requisitions during the period of 
April 1978 until March 1980 revealed many requisitions for 
very large quantities, presumably resulting from combined 
requisitions for more than one customer order, but reported 
on only one order. If such quantities are not extracted 
(by some kind of inspection) , they may ruin the averages in 
the BOM file and consequently the whole forecast. 

The way the system was developed may introduce a prob- 
lem after the system becomes operational. The system was 
designed and implemented by a project officer and two pro- 
grammers that were especially hired for this mission. The 
involvement of other people, and especially users, in the 
NARF's 500 Department was minimal and this means that a 
special effort will be required to train the users, acquaint 
them with the new tool, and make them efficiently utilize 
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the system. The lack of good documentation (because tho 
software was written by people that were hired for a very 
short period of time) will make that job very difficult. 
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V. THE PROPOSED MRP SYSTEM 



The proposed MRP system is designed to meet the same 
objectives as the temporary system, i,e., forecast of NARF's 
material requirements, maintain and update the required data- 
base, and provide the appropriate interface to the supply- 
support system. However, the introduction of ASKARS, as well 
as the problems that have been identified in the temporary 
system, require and provide the opportunity to introduce 
some improvements. And that is what the proposed system is 
intended to do. 

The intent of this chapter is to provide a functional 
design of the proposed system. It should serve as the basis 
for detailed design and implementation by NARF Alameda people 
after ASKARS becomes operational. 

The implementation of ASKARS raises the following factors, 
which will become important to the design: 

1, New ADP equipment will be installed. In addition, 
there will be new software and application programs; this 
requires compatibility between the system on which MRP will 
be run and ASKARS. A logical solution is to run MRP on the 
ASKARS ADP equipment. 

2. The available time for design and implementation of 
the proposed system is long enough to prevent short-cuts 
because of time pressures. 
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3. The implementation of ASKARS requires professional 
ADP people. 

4. ASKARS' software, and especially the order processing 
module [22; Enclosure (1), Section 5], has many similarities 
to MRP. The use of the same or a slightly changed approach 
in the design of the MRP system will increase the understand- 
ing of the MRP system and facilitate its implementation and 
maintenance . 

A major component of the proposed system is the algorithm 
for generation of the gross requirements. The fact that NARF 
Alameda performs mainly maintenance instead of production 
results in an uncertainty about the BOM information. This 
has been treated only in a minor way in the temporary system. 
Therefore, a considerable effort is devoted here to develop 
a better and more accurate algorithm to handle this uncer- 
tainty. 

Another important area that this system considers is the 
production schedule and the human resources (professions and 
standard hours) that are required to carry out the schedule. 
Since a production schedule file is not in existence at 
present, a simple application is proposed below. It will 
satisfy the MRP requirements as well as the basic needs of 
the production and control people. 

Production planning and control was also a major factor 
in the design of the BOM data structure. It provides the 
basis for inclusion of other resources in the BOM file. 
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This may contribute further to a better and accomplishable 
production schedule. This will not be developed here in 
detail, but will be outlined for further development in the 
future . 

A. PRM-MRP: PROBABILISTIC REPLACEMENT MODEL FOR MRP 

This section is devoted to the development of the proposed 
model for material requirements planning in a maintenance 
oriented facility. 

1 . The Demand Distribution 

The demand for an item in a maintenance oriented 
environment is determined by the following three factors 

a. The Production Schedule 

It determines the end items that will be reworked 
and thereby determines the set of consumable items that are 
candidates for consumption. The candidates are the compon- 
ents that make up the scheduled end-items. 

b. The Replacement Factors 

The replacement factor of a consumable item 
that comprises a specific end-item corresponds to the pro- 
portion of the installed quantity of that consumable item 
in one end- item that is expected to be replaced/consumed 
in the course of reworking the end- item. The replacement 
factor, P, takes on values such that where P=1 

represents consumables that are always replaced during repair 
of the end- item and P=0 represents components that are never 
replaced. The replacement factor is affected by maintenance 
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policies, experience of the people that do the maintenance, 
and by the nature of the item and the environment in which 
it is used. 



c. The Demand Distribution for the Item 
Being Replaced 

Let n^, U 2 , • • . , n^ be the installed quantities 
of a consumable item in m different end items IICj^, IIC 2 , 

. . . , respectively. Let Pj^, 5*2’ ’ ’ * ’ ^m corre- 

sponding replacement factors of that consumable item and let 
Qj, Q 2 > • • • » scheduled quantities per quarter for 

the end items. Let be a random variable representing the 
demand for the consumable item during the quarter for the 
scheduled repair of IIC^. Then, X^ has a Binomial distribu- 
tion, namely 

"iQi X. niQi-X, 

b(Xj;n.Qj,P.) = ( x.hPl 0 - Pj) ^ , i = 1,2 m 



The mean of the distribution is Lhe variance is 

riiQiPiCl - P^). [27:28,69]. 

Each X^ is an independent random variable because 
the demand for an item by an IIC is independent of the demand 
for that item by another IIC. 

Consider now the total demand for an item during 
a quarter. Let it be the random variable X. It follows 
that 

X = X, + X, + ... + X„. 

1 Z m 

The mean of X Cor expected value of X) is 



79 



E(X) - - 



m 

nOP = Sn.Q.P. [27:401. 
m^m m • . i^i i '■ ^ 

1 = 1 



Similarly, since X^,X 2 ,...,X^ are independent variables, the 
variance of X, Var(X),is 



Var(X) - riiQ]_Pi n2Q2P2<^^"P2^ 



m 

= E n.Q.P. (1-P.) . 
i=l " ^ ^ ^ 



The probability distribution of X can be approxi- 
mated (with continuity correction) by the Normal distribution. 

2 . The Basic Model 

Planning Horizon - -Repair schedules are developed on a quar- 
terly basis at the NARF. Additionally, the inventories of 
consumable repair parts are funded either from the Navy Stock 
Fund (NSF) if provided and managed by a NSC or by the Navy 
Industrial Fund (NIF) if purchased and managed by the NARF. 
Both funds serve as revolving funds which provide a fixed 
amount of money for a given quarter to buy inventories. 
Customers are billed for items used and submit payments to 
these funds. The money collected is returned to the NSC or 
the NARF at the beginning of the next quarter. Adjustments 
in the amount of money in either fund is made quarterly or 
less frequently depending on the variation in the production 
schedule . 

Because of the repair schedule and the nature of the 
NSF and the NIF, demand for repair parts appears to be inde- 
pendent from one quarter to the next. Therefore, the model 



80 



to be presented below will have a planning horizon of one 
quarter in length and will be what is known in inventory 
theory as a "single period" model [14: Chapter 6]. 

Objective - - In providing an inventory of repair parts the 
logical objective is to strive for a maximum availability of 
each item. If it is known that an item is replaced 1001 of 
the time during overhaul of an end item, then it is logical 
to stock for that 100% level. The MRP approach will determine 
the total quantity of such an item easily. 

If, however, an item is replaced less than 100% of the 
time, then stocking that item to the 100% level is going to be 
wasteful unless future quarters' production schedules are able 
to absorb any surplus. A surplus at the end of a quarter in 
absence of knowledge of future schedules results in NSF or NIF 
money being tied up which could have been used to buy more of 
some other item either in the upcoming or in the past quarter. 

Thus, a balance needs to be sought between the chance 
of a surplus and the chance of a deficit for the items not 
replaced 100% of the time such that the remaining funds in the 
NSF or NIF (after the "100% items" are purchased) are used 
efficiently. 

Objective Function - - The balance being sought above will be 
determined by developing an objective function which describes 
the expected costs for all the items not replaced at the 100% 
level as a function of the amount of each item to be placed in 
the RSS or NIF stores at the beginning of the quarter. The 
following costs are assumed to be appropriate for this function. 
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a. Processing Costs 

A special processing cost per unit, Cp , which is 
different from the procurement cost, is incurred to establish 
an item in the RSS or NIF's stores. If the quantity of an 
item going into a store is denoted by y then the total pro- 
cessing cost for that item will be represented by the product: 

C y. 

P 

b. Holding Costs 

The space required to store an item being demanded 
during the quarter must be large enough to hold all y units of 
the item. A unit cost, Cj^, is assumed to be incurred regard- 
less of how long a unit is in the store during the quarter. 

The total holding cost will therefore be; 

ChX. 

c. Penalty Costs 

Two forms of penalty costs should be considered. 

The first is a shortage cost for being out of stock at some 
time before the end of the quarter; the second is a surplus 
cost for having undemanded units of an item still in stock at 
the end of a quarter. 

In the case of a shortage, a unit must be obtained 
from outside the store. In the case of the RSS, this unit 
might be available at the NSC or it might have to be obtained 
somewhere else in the supply system. In the case of a NIF 
store it would probably have to be obtained from the appropriate 
DLA or GSA source. Concentrating on the RSS from now on, we 
assume a cost of per unit requisitioned from the NSC and a 
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cost of ^2 per unit requisitioned from outside the NSC. 

These costs should reflect the time delays resulting from 
having to go outside the RSS. It is reasonable to assume 
that << ir 2 * 

If demand X for an item exceeds y, the amount in 
the RSS, then the shortage cost will be: 

TT3^[X-y] , 

if X is not so large that the stock w at the NSC is also 
exhausted (that is, X £ y + w) . If X is so large that we 
must go to the outside, then the cost will be: 



TTiW + it 2 [X - y - w] . 

In the case of a surplus, the unit cost for having 
a surplus is assumed to be kC where C is the unit purchase 
cost and k is a factor which may be greater than 1.0. The 
cost of a quarter's surplus can be then written as 

kC [y - X] , 



and applies only if X < y. 

d. Expected Total Costs 

If we let p(x) represent the binomial probability 
that X units are demanded during the quarter for a given item, 
the expected total cost for the quarter can be written as: 



EC (y) 



y 

[C + C, ]y + T kC[y - X]pCx) 
P ^ X=o 



+ 



y+w 

E 

X=y+1 

00 



^1 



[X - y]p(x) 



( 1 ) 



^.^1^ tt 2 [X - y - w] }p(x) 
X=y+w+l 
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If the demand is sufficiently large that demand can be 
assumed to be Normal then 

ECCy) = [C + Cj^]y + /kC[y - X]f(x)dx 
^ o 

y+w 

+ / TT [X - y]f(x)dx (2) 

y 

+ f°° + tt 2 [X - y - w]}f(x)dx, 

y+w 

where f(x) denotes the density function for the associated 
Normal distribution. 

Optimal Order Quant ity - -The basic model seeks to determine a 
value for y ^ 0 which minimizes EC(y) in either the discrete 
form of equation (1) or the continuous form of equation (2). 

The calculus can be applied to equation (2) to get 
optimal y. Taking the first derivative of EC(y) with respect 
to y and setting it equal to zero results in 



F(y) = = 



TT^ + kC 



(3) 



where 



and 



F(y) = fy f (x)dx 



F (y + w) = f f(x)dx. 
^ y+w 



In the discrete case we want the largest value of y for which 

(4) 



■ [^2 ■ ^ 

P(y) > ^ ^ ^ 



TT + kC 
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where 



FCy) = 2 pCx) 

X=y 

and 

oo 

P(y + w) = 2 pCx) 

X=y+w 



This results from the analysis of finite differences in which 
we seek the largest value of y for which 



EC(y) - ECCy - 1) < 0. 



In the event that the NSC has a large stock outside 
the RSS we can assume w -► <» and equations (3) and (4) reduce 
to 



F(y) 



C + Cv + kC 
P h . 

+ kC 



( 5 ) 



P(y) 



> 



C„ + C, + kC 
P h 

7T^ + kC 



( 6 ) 



3 . Extensions of the Basic Model 

The basic model described above did not consider 
situations where two or more end items are demanding units of 
the same repair part and where a budget constraint limits the 
amount of units which can be purchased for each of two or more 
repair parts. 

Two End- Items Demanding the Same Repair Part - -To study this 
case, let X^ and X 2 be the units of a certain repair part 
demanded by end items Nos. 1 and 2, respectively. The total 
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demand X for the repair part is then the sum of and X^; 
namely , 

X = X^ + X2 . 

The surplus cost term of the expected cost for a 
quarter is the same form as above, namely, 

I kC[y - X]p(x) 

X=o 

or 

y 

/ kC [y - X] f (x)dx ; 
o 

except that now p(x) and f (x) are the probability and density 
function associated with a total demand of X. Since X is the 
sum of and X2 and since X^ and X2 are independent random 
variables we have a density function for X which is approx- 
imately Normal as discussed earlier. 

The shortage cost term is more difficult to develop. 
Let us assume that a quarter has a length of T time units 
and that the supply y of an item is exhausted at t time units 
after the start of the quarter. It follows that if t < T 
then a shortage will occur before the quarter ends. Let us 
also assume that the two end items consume at rates r^ and 
r2 where 

Xi X2 

^1 T ’ ^2 ~ T 

From knowledge of r^^ and r2 we can determine t since 
[i*! + r2]t = y . 
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Thus , 



t = 



X 



Jl. 






The shortage cost function for end item No. 1 will be 



then 



^11 f^l ■ ’^l^^ ~ '^11 f^l ■ T ^ X^+ ~ X2 



where ir^^jis the shortage cost associated with getting a unit 
of the repair part from the NSC for repair of end item No. 1, 
if the supply at the NSC can meet the total demand. Similarly, 
for end item No. 2, 

r V *1 ^12^2 

^12 [^2 ■ ^^2^^ " X^ + X 2 [X - y] . 

The sum of these shortage costs is 



TTiiXf 



^12^2 



Xi . X 2 



[X - y] 



and the expected costs of shortage can be approximated by 



/ 

y 



TTiiUi ^ 77^2^2 

Ul + P 2 



[X- y]f(x)dx 



if the NSC has a very large back-up stock. The terms and 
^2 correspond to the mean demand for the individual end items 
for the given repair part [28]. 

The expected costs for one repair part used by two 
end items can be written as 
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( 7 ) 



EC(y) = [Cp + Cj^]y + kC [y - X] f (x) dx 
+ fy [X - y]f (x)dx 

where 

_ ^ 11^1 ^ ^ 2^2 
^2 ‘ ( 8 ) 

The optimal value of y can be determined from equation (5) 
if TT^ is that given by equation (8) and F(y) uses the distri- 
bution of the random variable X where X = X^ + X 2 . 

More than Two End- 1 terns Demanding the Same Repair Part 

Equations (7) and (5) are still applicable when we have 
n end- items if we use 



X = X^ + 



* 



+ X 



n 



and 



^1 = 



^11^1 ^12^2 ^In^n 



V^l * \^2 * * * * ^ 



n 



The model, and the problems associated with providing 
the data it requires, are further discussed in Appendix E. 
However, the discussion in the following sections assumes 
that the necessary data will be available. 
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B. SUPPORTING INFORMATION 



The basic principles of an MRP system and an example of 
a system that satisfies some of the NARF ' s needs has been 
described in previous chapters. Therefore, the material 
presented hereafter will not repeat all the details and will 
assume that they are clear. 

1 . Outputs, Inputs and Data-Base 

The outputs of the proposed MRP system are basically 
the same as those of the temporary system. The main differ- 
ence should be in the accuracy of the forecast that the system 
generates . 

The system will produce the following' outputs: 

1. Material requirements forecast. 

2. Answers to queries about the forecast and the BOM 
f ile . 

3. Transactions for RSS level setting. 

4. Transactions for updating the ASKARS order processing 
module. 

The additional transactions generated by the MRP 
system are designed to provide the input to ASKARS that will 
allow using its existing software for follow-up on the trans- 
actions submitted to NSCO from submission until the material 
is received and placed in the appropriate bins in ASKARS. 

The types of inputs to the system and the data-base 
are the same as in the temporary system. The structure of 
the files and the fields in the records are different but 
basically the same kind of inputs are used to maintain 
similar files. However, there are two differences: 
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a. The input for maintaining a production schedule 
will be more involved but will upgrade the quality of the 
data-base. This subject is covered in detail in a special 
section on the production control subsystem. 

b. The material requirements forecast, which is an 
output of the system, will also be an input to another pro- 
gram that will use the same information to generate the 
order processing transactions for ASKARS. 

2 . Functions 

The MRP system will perform the following functions: 

a. Input edit. 

b. Query. 

c. Report generation. 

d. File maintenance. 

e. RSS level setting. 

f. Generation of information for requisition follow-up. 

g. Analysis to identify exceptions (in material usage). 

3 . Algorithms 

Four algorithms are needed for MRP. 

a. Extract data from given files according to required 
fie Ids/ sequence s . 

b. Sort files according to required fields/sequence. 

c. Translate FIG to IIC's and vice versa. 

d. Generate requirements for given quantities of IIC's. 

The first two algorithms are in fact utility programs 
that are usually provided with the operating system and can 
be used on any file. On the other hand, the translation 
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algorithm and the algorithm for generating the material 
requirements are specific to this application and will be 
developed later on. 

4 . Environment 

The environment for running the MRP system includes 
both time-sharing and batch processing. Time sharing is 
required for the queries whereas all other runs are in batch. 
ASKARS' operating system requires and permits both environ- 
ments [ 22 ] . 

5. Information Network 

Running the MRP system involves the 500 Department 
at NARF Alameda which is responsible for the application and 
some external activities that provide inputs to the system 
or use the system's output. Among those are NSC Oakland, 
the production and supply departments at the NARF, the 
ASKARS system and ASO. Figure 11 depicts the information 
network for the proposed MRP system. 

C. MATERIAL REQUIREMENTS ALGORITHM 

The algorithm for determining material requirements for 
repair of end-items is the. heart of the system and there- 
fore it will be described in full. 

The algorithm is expected to be called in two cases :- 

1. Queries. 

2. Generation of the quarterly material requirements 
forecast . 

The two instances differ in that a query will usually 
involve a single (or a small number of) end items whereas 
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Figure 11: Proposed MRP System -- Information Network. (Frequency 

of runs and volumes of transactions are given in 
Appendix B.) 
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the second case involves the whole production schedule. 

This implies that the algorithm should provide a means for 
calling it for more than one end-item. 

Another requirement is to allow the user (especially in 
queries) to provide either a FIC or an IIC and have the 
program do all additional work to get the end result. 

A calling sequence that will meet the requirements is 
CALL MRP(ID,T,Q,S,E) where:- 

ID = End-item identification code (input parameter). 

T = Type of identification code (input parameter) . 

a. "1” for IIC. 

b. ”2” for FIC. 

Q = End-item scheduled quantity (input parameter). 

S = Sequence code (input parameter) . 

a. "1” to specify first call. 

b. ”2” to specify that the subroutine was 
called previously in this computation. 

c. "3" to specify that there are no more end-items. 

E = Error code (output parameter) . 

Subroutine MRP will be called from other programs. The 
parameters will be either supplied explicitly by the user 
(ID,T,Q) or implied (S) by events (first item, EOF or special 
ID) . Of special importance is the sequence code that deter- 
mines what modules will be executed. This code is set to 
"1” by the calling program for the first end-item. Subse- 
quent calls will have the sequence code ”2” and when there 
are no more items the calling program will issue a terminating 
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call ( CALL MRP (9999 , 1 , 0 , 3 , 0) ) that will tell the algorithm 
to proceed to the next phase of summing up requirements. 

The MRP algorithm includes two phases of processing as 
shown in the block diagram in Figure 12. In the first phase 
the end-items are specified by the caller and used as access 
keys to the BOM (directly when end-item is an IIC or indirectly 
via the FIG to IIC translation table when the ID is for a FIG. 
Then, the BOM information and Q are utilized to compute "raw” 
material requirements and to write records (one per NSN) to 
the raw materials file (an intermediate file). This phase 
ends when the subroutine accepts the terminating call (S = 3) . 
This causes execution of Phase II which begins with sorting 
of the raw requirements by NSN, computing total requirements 
per consumable, and writing the result to the final output. 

Customer orders that are in the production schedule and 
have been started previously require special processing during 
RSS level setting. It is not of concern in queries since the 
material planner only wants to know the material requirements 
for a new job. 

Semi-finished jobs are processed by the Regenerative MRP 
model. The requirements for the rest of an unfinished job 
are determined by subtracting the actual consumption thus 
far on such a job from the material requirements for the 
whole job. The production schedule that is the input for 
RSS level setting will include uncompleted customer orders. 
However, the actual consumption on the customer order from 
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Note: Control flows from top to bottom and from left to right. 



Figure 12: MRP Subroutine Block Diagram. 
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the previous quarter will be extracted from the DHF and RSF 
(by customer order) and this temporary file (Expended Mater- 
ials file) will be another input to Phase II of the subroutine. 
This means that the Raw Material Requirements file and the 
Expended Materials file will be read in parallel (matching) 
and the gross requirements for -a consumable NSN will be 
derived by taking the difference between the total .forecast 
quantity for that item (computed by the PRM-MRP computation) 
from the Raw Material Requirements file and the total quantity 
for that item in the Expended Materials file. Figure 13 
shows the record layout for the Raw Material Requirements 
file. This file also contains the necessary information for 
computing the probability distribution function for the total 
requirement . 

The final output from the MRP subroutine will be later 
formatted in the calling program (or by a different program) 
to either write the level setting transactions or to display 
them on the terminal. 

Subroutine MRP involves some error checking and parameter 
validations. A list of the errors the program will look for 
is given in Table II. The successful completion or the 
detection of an error will be reflected in the E parameter 
of the subroutine which, in fact, is a return code. A 
return code which is other than "0” will cause the calling 
program to display an appropriate error message and, in the 
case of material forecast generation for RSS level setting, 
the exclusion of that end- item from the forecast. 
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TABLE II 



Errors Returned by Subroutine MRP 



Error Return 
Code* 


Corresponding 

Parameter 


Explanation 


00 




Successful call 


11 


ID 


IIC/FIC does not exist 


21 


T 


Invalid type (other than 
1 or 2) 


31 


Q 


Invalid quantity (must be 
an integer) 


41 


S 


Invalid sequence code 
(other than 1, 2 or 3) 


42 


S 


First call before a previous 
computation was completed 


43 


S 


S = 2 without a previous call 
with S = 1 


44 


S 


S = 3 and other parameters 
not as required 


49 


s 


Warning. S = 3 without 
S = 1 or S = 2 . 



* The return call is an output parameter and is checked by 
the calling program. 
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Figure 13; Raw Material Requirement Record Layout. 

Figure 14 shows the detailed flow-chart of the subroutine. 

The subroutine will require approximately 150 lines of 
high- level- language code. When executed, it requires on-line 
storage for the BOM file, the Inventory Status file (MSIR 
Extract), the FIC to IIC translation table, and the Raw Material 
Requirements file. In addition, memory is required for input 
and output buffers and for the table created by the subroutine 
for issuing calls by IIC when the original call is by FIC. 

These resource requirements add up to approximately 50K Bytes 
of memory and 100MB of on-line storage. 

D. THE PRODUCTION CONTROL SUBSYSTEM 

The existence of a production schedule is one of the MRP 
prerequisites. Since the present production and control 
system at NARF Alameda does not provide satisfactory and up 
to date information, there is a need to develop the appro- 
priate software and maintain the required data base that 
will satisfy the proposed MRP application. 

The Production Control Subsystem (PCS) is designed to 
produce the following outputs: 

1. Production schedule listings. 
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Figure 14: Flow Chart o£ the MRP Algorithm 
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(continued) 



2. Answers to queries about the status of customer 
orders . 

3. Input edit reports. 

4. Progress and exception reports. 

Production schedule listings will be produced in two 
different sequences. The first sequence will list all 
customer orders that exist in the data-base. This report 
will be used by the production planners in the 500 Department 
and the production department head (900 Department). The 
report in the other sequence will be used by branch heads in 
the 900 Department and each report will contain only the 
customer orders with which the shop is involved. Both 
reports will contain the same information but in different 
sequences of customer orders. 

The queries will provide essentially the same information 
as the production schedule listings. However, the query will 
refer to one customer order only and will display the rele- 
vant up to date information. The queries will be by customer 
order, by FIC or by IIC. 

The intent of the input edit report is to give the status 
of the transactions that were submitted to the system. Trans- 
actions that contain errors will show up in the report with 
appropriate error codes specifying what the error was; for 
example, invalid record type, invalid dates or missing data 
items . 

The progress and exception reports will resemble the 
production schedule listings in format. The difference will 



101 



be in the information printed in the reports. This informa- 
tion includes standard hours for completion of the whole job, 
number of hours expended in the job since the previous edi- 
tion, and exception messages for those customer orders in 
which progress was not satisfactory. 

Two generations of the Production Schedule file will be 
used to produce such reports. They will be one month (or 
two weeks) apart according to the frequency of printing of 
a report. The progress in a job will be computed by subtract- 
ing total expended hours recorded in the previous generation 
of the file from hours expended in the same job until the 
present time. This progress will be analyzed to determine 
if it is satisfactory. The criteria for classifying a 
customer order as an exception will have to be set up by the 
production control people. Some possible criteria are listed 
below: 

1. Expended hours exceed standard hours by more than 20 
percent . 

2. The proportion of expended hours relative to standard 
hours is less than 70 percent of the proportion of 
time that elapsed relative to the total duration 
required for completion of the job. 

3. More than 20 days have passed since the latest 
required finish date and the job has not been 
finished yet (or not reported as finished). 

This report will also be produced in two different 
sequences: a listing of all exceptional job orders and 

another listing by shops/job orders. 

The inputs to the system will come from two sources: 
transactions reported by the production control department 
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and inputs that were generated by other applications. Among 
the last group are inputs about standard hours from the Master 
Data Record (MDR) file, expended labor hours from the Sorted 
Labor Transaction (,SLT) file and induction data from the 
Sorted WIP (work in process) History Activity file [23] . The 
transactions that will be written especially for the system 
are intended to maintain information about planned induction 
quantities and scheduled dates of the different job orders. 
They will also allow changes in the status of job orders. 

The transactions will allow reporting on individual job 
orders or on a whole FIC. This last option is especially 
needed for reporting a new production schedule. A simple 
data entry program can simplify the process of reporting the 
transactions mentioned above. Figure 15 depicts the layouts 
of the different inputs that the system will process. The 
MDR data will be extracted directly by the PCS file mainten- 
ance module and therefore the standard hour information will 
not show up in these layouts. The different transactions 
will be edited by an input edit program that will check the 
different fields for validity. Other fields, like the job 
order and transaction code, will be examined later by the 
file maintenance program to make sure that when the code 
specifies an update, the job order already exists. 

To perform its functions, the system will maintain a 
PCS file that will store the information about the various 
job orders. The file will be a direct access- variable- length 
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Transaction Codes: "1" - new data 

"2" - update data 

Sorting Key: 2-8, 1, 28; ascending order 

The job order data (FI C Transaction) is required to compose job order numbers. 




record file. A logical record will consist of three basic 
structures : 

1. A header for each FIC/FY/Quarter . 

2. Job order trailers for jobs belonging to the above 
FIC/FY/Quarter. 

3. Shop trailers for shops participating in the above job 
order . 

Each such record will store the information about a particular 
FIC which is scheduled for a specific quarter (i.e., if the 
file covers a period of one year, there may be 1 to 4 differ- 
ent records with the same FIC) . The tree structure of a 
logical record is depicted in Figure 16. The file will be 
accessed by FIC/FY/Quarter. However, this index and the 
translation subroutines from FIC to IIC and vice versa and 
from job order to IIC will allow direct access to the file by 
either job order or IIC, fiscal year and quarter. Figure 17 
depicts the layout of each one of the PCS record components. 

The header information contains information about a FIC 
that is scheduled. Each job order trailer represents one of 
the specific job orders in which an IIC belonging to the FIC 
will be overhauled. The job order trailer contains summary 
data about the job order and allows access to its shop trail- 
ers which contain information (namely standard and expended 
hours) about each shop that participates in the job. 

The status of a FIC or a job order represents the situa- 
tion of a group or a specific job respectively. The status 
can be one of the following: 
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Figure 16: PCS data structure. 
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(5) Average number of job order trailers per record = 2; Maximum = 40. 

(6) Average number of shop trailers per job order = 60; Maximum = 160. 

(7) Maximum record lengtii = 44 + 42 x 40 + 21 x 160 = 5084 Bytes. 







r; 



blank - The job has not been started yet. 

"W” - The job is in process (i.e., expended hours 

are positive) . 

”C" - The job has been cancelled. 

"F" - The job has been finished. 

Since the FIC header represents a set of job orders, its status 
will reflect the status of its composite set of job orders. 

The header status will be changed to "W when the first job 
has been started. Similarly, it will be ”F" only after the 
last job has been finished. The status can be changed to "C" 
only by a status reporting transaction (see Figure 15). Con- 
sequently, the "date of status" field will represent the date 
of the last change in status. 

The production control subsystem software will include the 
following modules: 

1 . Input Edit 

This module will validate individual data fields and 
will print out records that contain erroneous data. 

2 . File Maintenance 

This involves performing further validity checks on 
good records from the previous step and subsequently updating 
of the PCS file. The FIC transactions will be the first to 
update the file. These transactions will cause the creation 
of new FIC headers, and then job order trailers with predicted 
quantities (based on relative frequencies of IIC's) and shop 
trailers with standard hours from the MDR. Subsequently, 
other transactions will update or add information to that 
which was generated by the FIC transaction. 
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3 . Queries . 

4 . Report Generators . 

Production schedule listings and exception reports. 

Figure 18 describes the information network and the data 
flow. It also shows how the induction data for updating the 
BOM file is extracted from the PCS file. 

One advantage introduced by the proposed PCS is the 
continuity of the production schedule, i.e., a job order 
stays alive until it is finished or cancelled. In this way, 
customer orders that were not completed in the scheduled 
quarter are carried over to subsequent quarters until they 
are completed. This saves the work of reevaluating the re- 
quirements for end-items when preparing each quarter's 
production schedule. 

The production control system described above can be 
run on the 500 Department ADP system that is used to run the 
temporary MRP system. Weekly runs appear to be more than 
adequate at this time. On-line updates may be required in 
the future, however. 

It is recommended that implementation begin with only 
transaction updating, even though such information may exist 
in a mechanized form in another part of the system. While 
this may result in extra manual work, it has the advantage 
of simplifying and increasing the involvement of the produc- 
tion control people in the system evolution. 
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Figure 18; The Production Control Subsystem (PCS). 
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E. DATA-BASE DESIGN 



The additional data files that are required for the MRP 
application are designed below. 

1 . The BOM File 

Carrying out a production schedule requires personnel, 
facilities and money (for contracting out repair of special 
components) as well as materials. The basic MRP technique 
computes only material requirements. However, it will be 
desirable to incorporate in the same file the information 
about all required resources and thereby provide a tool for 
comprehensive production planning. 

When considering all resources (except facilities), 
the information about each end- item should contain the 
following: 

1. End- item information- - including money for contracting 
out . 

2. Consumable materials information. 

3. Labor hours information. 

This implies that the records for each IIC should 
have a tree structure with a root, being a header containing 
the end- item information and two branches, one for materials 
and the other for labor hours. Each branch would be a set 
of fixed length records representing either a material or a 
shop's labor hours. Figure 19 depicts the structure of an 
lie's logical record. 



Ill 



Header 




"Consumable” Trailer 

Figure 19: BOM Data Structure 



As shown in Figure 19, for each IIC there will be 
one header, one consumable trailer per consumable item and 
one shop trailer per participating shop. The information in 
the header will allow access to the trailers by either having 
there a pointer or the number of different trailers. Figure 
20 depicts the layout details of the header and trailers. 

An important factor in designing the BOM is the fact 
that the NARF is involved in maintenance rather than produc- 
tion. The implication of that fact is that instead of having 
a BOM that experiences only addition of new IIC's, as in the 
case of manufacturing, the file will require changes to 
existing data, namely the replacement factors. Also, there 
must be a distinction between estimated replacement factors 
(representing new or modified items) and items that have 
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(3) Maximum record length = 47 + 1200 x 37 + 160 x 20 = 47,647 Bytes. 

(4) Maximum buffer = 47 + 150 x 37 + 160 x 20 = 8797 Bytes. 



already been overhauled. The process of maintaining the 
replacement factor data is described in Appendix D. 

The file will be an index- sequential file with the 
lie being the access key. When only the FIG is known, access 
is possible by using the FIG to IIG translation table. Appro- 
priate read/write functions will make it simple for applica- 
tion programs to access the file. 

The implementation of the shops branch in the BOM is 
independent of the other parts. Since the integration of the 
inventory and production control applications at NARF Alameda 
is not going to take place in the near future, it is recom- 
mended that the implementation of this part be postponed 
until the materials segment works properly and the organiza- 
tion is ready to manage the rest. Deletion of the shop data 
can simply be achieved by reporting only materials data to 
the system. This will create IIG records with no shop 
trailers. Because the shops branch will not be implemented 
with the rest of the system, this part will not be included 
in the file maintenance design. 

2. FIG to IIG Translation Table 

The intent of this file is to provide the data for 
translating a FIG end- item identification into the specific 
IIG’s that comprise it. The file also allows the opposite 
translation from IIG to FIG. Finally, the file provides the 
relative frequency with which the specific IIG's are expected 
to be inducted. This last element is vital for the transla- 
tion of a production schedule by FIG into an IIG schedule. 
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The file will be composed of fixed length records, 
one record per IIC. The organization of the file will be 
such that all records for one FIC will be organized sequen- 
tially. Therefore, to find the composition of a FIC, one 
has to access the file and read it sequentially until the 
record contains a different FIC. Figure 21 depicts the 
organization and record layout of the file. 





IIC^ 






IIC2 




FIC^ 


IIC 3 






IIC 4 




FIC2 


IIC 3 




IIC^ 




FIC 3 


llCj 










FIC 


IIC 


Total 

FIC 

Quantity 


Total 

IIC 

Quantity 


Relative 

IIC 

Frequency 


NSN 
of IIC 


1-4 


5-8 


9 - 14 


15 - 20 


21 - 22 


23 - 35 



Figure 21: FIC to IIC translation file record 

layout . 
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3. Other Files 



A file that has not been designed yet is the inventory 
status file. This file should contain information about all 
NSN's involved in the requirements forecasting process. The 
easiest way to get that data will be to get an extract from 
NSCO's MSIR which will contain all records related to items 
stored in the RSS. Using that file will save its maintenance 
by the NARF. Since the information about the quantities is 
not used by the MRP application, it will be sufficient to have 
a new copy of the file each week or two. Figure 22 depicts 
a layout of this file that will satisfy the proposed applica- 
tion. Any similar structure that is readily available is also 
satisfactory. 



NSN 


COG 


U/I 


U/P 


Nomenclature 


RSS Qty 
On Hand 


RSS Qty 
On Order 


Date of 
Last 


Wholesale 
Qty on 
















Trans . 
(Julian) 


Hand 


1 13 


14 15 


16 17 


18 27 


28 41 


42 45 


46 49 


50 53 


54 57 



Note : Any other structure that contains these fields is 

acceptable . 

Figure 22: MSIR Extract Record Layout. 

Another file that will change with the implementation 
of the proposed system is the MRP forecast file. The infor- 
mation that was added to the file for current production 
control needs will no longer be required. However, some 
method will still be needed for computing the distribution 
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of the gross requirements. Thus, the appropriate new struc- 
ture is shown in Figure 23. 



FIG 


IIC 


NSN of 


iNSN of 


u/i 


U/P 


NSN of 


COG of 


Installed 






FIG 


IIC 






Consumable 


Consumable 


Quantity 
per IIC 


1 4 


5 8 


9 21 


22 34 


35 36 


37 44 


45 57 


58 59 


60 62 



IIC Scheduled 


Total* 


Extended Price 


Quantity 


Requirement 

Quantity 


per Consumable 


63 65 


66 69 


70 77 



* Replacement factor - total requirement/ (IIC Scheduled 
Quantity * Installed Quantity). 

Figure 23: MRP forecast record layout 

F. SOFTWARE DESIGN 

The software of the proposed system will consist basically 
of the same modules as the temporary system. The differences 
are in the contents and in the set of functions that will be 
used by the different modules. Figure 24 depicts the block 
diagram of the main software modules. 

1 . File Maintenance 

This module consists of the programs to maintain the 
BOM file and the FIG to IIC translation table. The MSIR is 
not maintained but reproduced whenever needed and the Material 
Forecast file is generated by the requirements generation 
module and updated by queries. 
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Figure 24: Software Modules 



a. BOM File Maintenance 

The intent of this module is to update the BOM 
file with respect to the composition of the end-items, the 
replacement factors of the components, and the labor hours 
and shops participating in the job. 

The information that will update the BOM will 
come from two sources 

1. Transactions written by the material planners. These 
are intended to introduce new items or to update the 
file after technical modifications have taken place. 

2. Expended materials and labor hours. This historical 
data will be used to update previous data in the file. 

The file maintenance process consists of three 
steps as depicted in Figure 25. The first step deals with 
collection of the various inputs Ciri<iuction data, expended 
materials and labor hours and the transactions written by the 
planners) into one file. This program receives a parameter 
that tells the program the date of the previous BOM maintenance 
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Figure 25: BOM File Maintenance Run 
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run and scans the production schedule file for jobs that were 
completed after that date. For each completed job the program 
writes to the output file one induction data record (type 1 
record as shown in Figure 26) and a set of shop data records 
(type 8 records). These latter records contain expended 
hours by one shop on the specific job. At the same time the 
job number is entered into a table of completed jobs. When 
the end of the production schedule is reached, the table is 
used as a look-up table for extracting expended materials from 
the DHF and the RSF. For each record that belongs to a job 
that is in the table, the program writes a type 4 record 
(requisitioning data) . 

The second step simply sorts all inputs and pre- 
pares them for the final step in which the transactions are 
validated and used to update the file. The sorting is based 
on columns 1-22 (IIC, record type, NSN/shop, date). Ascending 
order will assure that the transactions with header informa- 
tion will be processed first, and later transactions for 
materials and labor hours (i.e., in the same order that the 
trailers are organized in the file). 

Type 1 transactions are also used to create/add 
new lie's to the BOM file. Type 3 and type 6 transactions 
provide the additional consumable items and labor hours in- 
formation required to forecast requirements. Types 1, 4 and 
8 transactions are used to compute actual average quantities 
of materials and labor hours. 
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Figure 26: BOM file maintenance transactions 
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As mentioned earlier, the transactions are sorted 
by lie and by the type of header/ trailer the data in the 
transaction is to update. Consequently, the update process 
treats each IIC that has transactions individually, starting 
with creating/updating the header, creating/updating consum- 
able's trailers and finally creating/updating shop trailers. 

The process of updating an IIC begins with reading a transac- 
tion that contains an IIC different than the IIC in the 
previous transaction. This causes an access to the BOM in an 
attempt to read the IIC's old data. If the IIC existed, the 
transactions are considered as changes; otherwise they will 
create a new IIC entry in the BOM. In this case there is a 
requirement to have additional transactions with material/shop 
data. 

The process of updating trailers is also designed 
to treat individual trailers separately (i.e., one consumable 
or one shop at a time). The induction data transaction is 
processed first and all it does is to save the induction 
quantity in memory. Subsequently, material estimate trans- 
actions (or shop estimates) simply update the appropriate 
fields in the trailer, whereas for a requisitioning (or shop 
data) transactions the expended quantity is computed and 
divided by the induction quantity to give a new average con- 
sumption. This average is exponentially smoothed (see 
Appendix D) with the old data and the updated information is 
saved in memory. In the course of processing these transactions 
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the program will also have to verify that all data fields 
contain valid data. 

Another function that the program performs is to 
detect exceptional replacement factors. Whenever the differ- 
ence between the old and the new factors is greater than 0.2 
(or any other value that can be selected) the program will 
print the data in the input edit and exceptions report. This 
report will have to be checked and, if there was an error, the 
appropriate correction should be made. 

Figure 27 describes the main functions that will 
be performed by the BOM file update program when treating an 
lie. Although the flow chart appears to contain many details, 
it is intended as a summary rather than the actual flow chart 
of the program. It must also be remembered that the labor 
hours branch will be implemented at a later time so that it 
is too early to go into more details than are needed to 
describe the general process. 

The complete BOiM file maintenance run will be 
executed once per quarter. This run will take place a short 
time before the workload conference so that an up-to-date BOM 
file will be available for generating the material require- 
ments. However, runs that just process transactions reported 
by the planners can be run at any time so that nev; data would 
lot have to wait up to three months before being processed. 
/Weekly runs for such purposes are probably sufficient. 
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Figure 27: Updating IIC Data in the BOM File 
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Figure 27: (continued) 
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Figure 27: (continued) 
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b. Maintenance of the FIC to IIC Translation Table 

The maintenance of this file has two goals 

1. Update the file with new end-items. 

2. Update the relative frequency of IIC's. 

The information from the Quarterly Family Tape 
(QFT) will be used to keep track of all existing end-items. 
This file is maintained by ASO and is delivered to users on 
a quarterly basis. It contains one record per IIC and each 
such record contains the FIC to which that IIC belongs. 

The relative frequency of IIC's will be updated 
by the induction data. A record will be provided for each 
induction, containing the IIC that was inducted, the induc- 
tion quantity, and the FIC. The input will be sorted by FIC 
and IIC and by ascending record type ("1" for QFT records and 
"2" for induction data). 

The principle used in updating the file is to 
update all information about a FIC as one unit. Therefore, 
for FIC's that have transactions, their records from the old 
file are read into an array in memory. Then the transactions 
update appropriate quantities or open new entries for new 
IIC's and at the end of the FIC, updated records are written 
to a new file. FIC's that have no transactions are just 
copied from the old to the new file. 

Figure 28 depicts the maintenance run and 
Figure 29 is the flow chart for updating one FIC. 
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igure 28: FIC to IIC Translation Table File Maintenance 
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Figure 29: Updating FIG Data 
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2 , Queries 



Implementation of the proposed system will require 
conversion of the temporary system software to fit the new 
data-base. The use of the MRP subroutine will simplify signif- 
icantly the query program and will usually require a simple 
"driver" program that will prompt the user and translate his 
inputs into appropriate MRP subroutine calls. 

To facilitate use of the system, "query numbers" will 
be assigned to each type of query. They will allow the user 
to choose the query type dynamically. In the selection mode 
the system will display all alternate queries available for 
use and let the user specify his choice. This will then cause 
branching to the appropriate module that will retrieve the 
requested information. 

Figure 30 depicts the block diagram of the query 

module . 

3 . Requirements Generation 

This module will be significantly different from the 
one in the temporary system because the proposed requirements 
generation program will consider job orders that are already 
in process and because the use of the MRP subroutine will 
simplify the program. 

The generation of the requirements will consist of 
several steps, as shown in Figure 31. The first step scans 
the production schedule file to extract and build a list fin 
memory or as a temporary file) of all job orders that will 
be worked on during the coming quarter. This means that an 
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Figure 30: Query Module Block Diagram 





Figure 31; Material Requirements Generation Run 
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mtry will be opened for each job order whose planned period 
rails in the coming quarter and whose status is blank, ''W or 
’P". Each such entry (or record) will contain the job order 
(which contains the IIC) and the scheduled quantity. 

The next step will use those job orders as a table to 
jxtract from the DHF and RSF the materials that have already 
)een expended in continuing job orders. The output of this 
>tep is the Expended Materials file. 

The third step is the actual preparation of the MRP 
’orecast file. In this phase the program issues calls to the 
IRP subroutine and transforms the output from the subroutine 
:nto records with the structure of the MRP Forecast file. 

After the material planners finish updating the MRP 
-orecast file, the computation of the requirements for each 
:onsumable item is performed. To do that, the intermediate 
:ile that subroutine MRP needs is regenerated from the final 
IRP forecast file and both the intermediate file and the 
Expected Materials file are input to the program which issues 
i terminating call to subroutine MRP. The subroutine then 
ises the proposed model to generate the final requirements 
forecast. This output is formatted into RSS level setting 
:rans,actions (AOA transactions). 

4 . General Purpose Subroutines 

The MRP application involves several functions that 
(fill be performed by several programs. It will be very useful 

^They can modify only the "total requirement quantity" 
:ield--see Figure 23, columns 66-69. 
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to have those modules shared by the different programs, thereby 
saving programming effort and assuring consistency. 

A set of such functions are the read/write functions. 
The application involves several variable - length- record files 
which may present a problem to novice programmers. The prob- 
lem can be solved by a set of I/O routines. Each routine will 
perform either read or write. It will be called with param- 
eters that will specify the program’s need and will return 
(or write) a complete logical record or a required header/ 
trailer. Some additional work can be saved by having the 
various data structures in software libraries. Those struc- 
tures would be copied by user programs and would save the 
definition by each one. 

Another subroutine that will be required is a sub- 
routine that accepts the mean and variance of a random var- 
iable that has a Normal distribution, and a desired cumulative 
probability and provides the value that satisfies that proba- 
bility, This function would not have to be written by local 
personnel but can be bought from software vendors. This 
function is required for the application of the proposed 
model . 

Another required subroutine is one which identifies 
the lie that is being overhauled in a given job order. The 
lie is contained in the job orders but its position is dif- 
ferent according to the production program the job belongs to. 
By maintaining a table of the positions of the lie in various 
job numbers, one can easily identify an lie from a job order. 
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rhis function will be needed to allow access to the production 
schedule or to the BOM file when only a job order is given. 

SYSTEM CONFIGURATION 

The intent of this section is to identify the computer 
resources that will be required for running the proposed MRP 
ipplication. The sources that were utilized in estimating 
the resources are: 

1. The information about the temporary MRP application. 

2. Comparison of complexities of the existing and proposed 
software and data-base. 

3. Personal experience of the author with similar systems. 

This analysis takes into account an annual file size and 

orocessing growth factor of 10 percent and assumes a useful 
Life period of ten years [26]. 

1 . On-Line Storage 

On-line storage is required for the data-base, work 
areas, and software libraries. The last two elements can be 
ignored here because of their relative small size and also 
Decause they are shared by other applications. 

Table III shows estimates of the net sizes of the 
irarious files. When considering inter-record gaps of 30 bytes 
and allowances of 10 percent for overhead and indices, the 
required storage becomes (118924 + 30 x ^ ~ 

(Vhen the future growth during the useful life of the system 
is included, the requirement at the end of ten years becomes 

207 X (1.1)^ == 488MB for on-line storage. 
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TABLE III 



File Sizes 



File Name 


"Record” Name 


# of Records 


Record Length 
(Bytes) 


Net Size 
(K- Bytes) 


BOM 


lie header 


14,000 


47 


658 




eonsumable 

Trailer 


700,000 


37 


25,900 




Shop Trailer 


170,000 


20 


3,400 


FIC to lie 


lie Record 


14,000 


35 


490 


Translation 

Table 










MRP Forecast* 


eonsumable 

Record 


1,000,000 


77 


77,000 


vlSIR Extract* 


NSN Record 


40,000 


57 


2,280 


Production 


Fie Header 


20,000 


44 


880 


Schedule* 












Job Order 
Trailer 


28,000 


42 


1,176 




Shop Trailer 


340,000 


21 


7,140 


Total 




2,306,000 




118,924 



* Numbers of records were inflated to represent required capacity 
at war time. 
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This storage quantity is less than 30 percent of the 1200 MB 
disc storage that ASKARS will have as a minimum [22:3.3.8]. 

2 . Off-Line Storage 

The required off-line capacity imposes no constraint 
except to tape drives. Two tape drives will allow copying of 
files, taking back-ups, and running the programs that ivill 
usually have input (transaction) tapes. 

3 . Main Memory 

Main memory is required for programs (and their I/O 
buffers) that are run simultaneously. Since file maintenance 
and queries would not run concurrently, main memory require- 
ments are computed for the file maintenance module and the 
general purpose subroutines. As Appendix C shows, the length 
of those modules is 2000 + 450 = 2450 high level language 
statements. Assuming an average of 10 machine instructions 
per statement and an average of 6 bytes per instruction, the 
total main memory amounts to 2450 x 10 x 6 = 147000 Bytes. 

When adding buffers for the BOM file (t:: 8.8KB), the production 
schedule file (5 KB) FIG to IIC translation table (35 bytes) 
and transactions (80 bytes) , at least 165 KB are needed in 
addition to the memory resident operating system modules. 
However, it must be noted that systems whose operating system 
provides virtual memory may utilize less real memory. 

4 . Processing Time 

When computing processing time, one has to distinguish 
between three different modes of operation during a quarter, 
each of which requires different processing capacities. 
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The highest capacity is required when the mainte- 
nance of the BOM file takes place (once per quarter in the 
third month) and when the MRP Forecast file and RSS level 
setting transactions are generated. A lower capacity is 
required for maintaining the Production Schedule file (at 
least once a week). The lowest, but most frequently required 
capacity is for the queries. 

This imposes a changing load on the system and it 
will require timing the execution of various programs to 
prevent temporary peak loads. 

In estimating the total processing time for MRP and 
PCS, the following assumptions are made: 

1. 10 Machine instructions per statement. 

2. Average clock pulses per instruction = 12. 

3. Clock rate = 3 MHZ. 

4. During file maintenance, one-half of all statements 
are executed for each transaction. 

5. During queries, one-fourth of all statements are 
executed once per query. 

6. In report generating type programs, each statement 
is executed once. 

Applying assumptions 1 through 3 gives an average 
statement execution time of 10 x 12 x y = 40 ysec. 

When using this average execution time with the input 
rates from Appendix B, the program sizes from Appendix C, 
and the processing capacity as shown in Table IV, and when 
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Processing Capacity 



Total Statements 
Executed per Qtr 
(x 1000) 
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applying the 10 percent annual growth factor, the total 
quarterly execution time during the tenth year of operation 
amounts to: 



483450 X 10^ X 40 X lO'^ x x 

ioUU 



. statements . 
^ qtr 



0 



sec . 
stat . 



. hours 

^sec 



( 1 . 1 )^ 



= 12.7 hours per 
quarter . 



During the first year of operations the system will 
require only 5.00 hours per quarter. 

5 . Conclus ions 

The resources that are required for running the MRP 
application are relatively small. The computations above have 
taken into account not only the MRP system but also the PCS. 
Even including future growth, the processing time does not 
justify devoting a computer to this application. 

The conclusion is that the application should be run 
on an existing system and the system that appears to be 
appropriate is ASKARS. The reasons for selecting ASKARS' 
computer system are three- fold: 

1. The MRP system plans materials which are carried and 
later handled by ASKARS. 

2. ASKARS is a redundant system and therefore the addi- 
tional load on the system would be insignificant. 

3. The ASKARS system will hopefully have skilled ADP 
personnel (as opposed to the PDP 11/70 on which the 
temporary system runs) that could handle such a project. 
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H. COSTS AND BENEFITS 



The purpose of the following analysis is to compare the 
costs involved in implementing the proposed system and to 
explore the benefits it will provide. 

The costs involved in implementation of the MRP system 
are of two types: one-time development costs (software 

development) and recurring costs for software and hardware 
maintenance, supplies, personnel, and payments for computer 
time. Although ASKARS' processing and peripheral equipment 
have already been accounted for ("sunk cost") we will assume 
in this analysis that there is a capital cost associated with 
using the MRP application in ASKARS and that it can be computed 
according to the proportion of CPU time the MRP uses relative 
to the total CPU time available. We will also assume that 
the annual depreciation cost of this equipment is 10 percent 
of the purchase price. Consequently, the annual allowance 
for hardware is 

HC = [PC/10] X [T^/T2] 

where; HC = annual allowance for MRP hardware costs 

PC = purchase costs of the complete system 

T-i = CPU time for MRP. We will assume an average 
of 10 hours per quarter (see section G.4 of 
this chapter) . 

T~ = total CPU time available per quarter. Since 
^ there are two processors, 

T 2 = 2 X 90 X 8 = 1440 hours. 

Since the procurement of the ASKARS system is now in the 
bidding phase we will assume that the cost of the ADP equipment 
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is 50 percent of the total cost of the ASKARS sys;em. The 
latter is estimated to he $2,513,500 [26J ; consequently, the 
cost of the ADP equipment in that system would be approxi- 
mately $1,257,000. Using these figures, the hardware costs 
would amount to less than $1000 per year. 

Allowing 10 percent of that amount for hardware mainte- 
nance, the MRP's share of hardware maintenance costs will be 
approximately $100 per year. 

Software maintenance will be assumed to require one 
programmer and 1/6 of one analyst (based on development per- 
sonnel). In addition, the system will need two clerks for 
handling inputs and outputs. Using an average annual salary 
of $30,000 a year, including fringe benefits, the personnel 
costs for software maintenance and operations would be: 

(1 + 1/6 + 2) X 30,000 = $96,000 per year. 

When using the software development times from Appendix 
C and the above annual salary, the development and training 
expenses amount to 

( 75 ^ 5 _, + J4.2 + 0.2 + 1. 0 .,. + , 8 .. . Oj 30,000 = $247,250 

To that we have to add processing time of approximately three 
months during the development period (HC x 4/2 = 330) to get 
a total of $247,580 for development costs, or approximately 
$25,000 annually to be added to the recurring costs. When 
adding all these costs, we find that the annual costs of 
running the system are $122,100. 
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The benefits from implementing the system are more diffi- 
cult to measure, although relatively easy to identify. The 
system will provide the material planners a good data base on 
which they can base their decisions. It will also save them 
time by providing the necessary reports and inquiry capa- 
bilities (although this is not intended to totally replace 
their being in the shops!). The system will also provide a 
better requirements forecast and thereby improve availability 
of materials for repair and availability of ready- for- issue 
items that would not be delayed in the process of repair. 
Another area of savings is in workers' time. Because of 
improved availability of materials, work stoppages are ex- 
pected to go down, thereby reducing the need for "backrobbing" 
(i.e., removal of parts from an aircraft/component for use on 
another aircraft/component with an earlier scheduled comple- 
tion date [21:16]). 

Another very important advantage of introducing MRP is 
the fact that the improved forecast should lower the amount 
of money tied up in inventories and should release that money 
for use elsewhere. 

The factors that have been mentioned above gave a quali- 
tative description of the benefits; quantifying some of them 
will clarify the description. During the period 1 April 1978 
thru 31 March 1979 NARF Alameda's work centers charged 21,186 
production delay hours to backrobbing. These hours represent 
a cost of more than $860,000 [21:16] per year. Expenditures 
on material planners’ salaries amount to approximately 
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.22 X 30,000 = $3,660,000 a year. Saving 1 percent of their 
:ime represents $36,600 per year and the system will doubtless 
;ave more than that. When adding to that the money expended 
>y the NARF on materials -- being almost $60 million in 1978 
’22]--it becomes obviously clear that the annual benefits will 
exceed the $122,100. 

Another aspect that is worthy of consideration is that 
;he MRP system may also be implemented at other industrial 
ictivities in the future so that the initial investment in 
:his system can be expected to reduce the investment in those 
;uture systems. 

:. IMPLEMENTATION PLAN 

Implementation of the proposed system should consist of 
:he following phases 

1. Establishing a development team. 

2. Software design, programming and documentation. 

3. Conversion of the data base. 

4. Testing. 

5. Training and parallel operation. 

6. Post implementation reviews and improvements. 

The development team should consist of systems analysts, 
irogrammers and user representatives and should be responsible 
for preparing a detailed implementation plan, detailed system 
iesign and implementation of the system. This thesis would 
Provide the team with design guidelines. 
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The various activities that take place in each phase are 
described in detail in Appendix C. Figure 32 gives anticipated 
project schedules for implementation of the system as well as 
the system development activities and human resources that are 
needed in each phase. 

When going into actual implementation, it will be very 
important to keep in mind Woolsey's [24] "Ten ways to go down 
with MRP." Among others that he mentions, the following should 
be regarded carefully here: 

1. "Only involve the highest level of management in defining 
the 'hands-on' side of the system." 

2. "Don't run the system in parallel, just shut down the 
manual system and turn on MRP." 

3. "Don't clean up your bills of materials, you know they 
are right." 

4. "Don't require sales to take responsibility for screwing 
up the master production schedule." 

5. "Install the system as a surprise to Production and 
Sales . " 
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Figure 32: System Development' and Implementation Activities 



VI. CONCLUSIONS AND RECOMMENDATIONS 



The MRP technique is designed to use the fact that the 
material requirements in a production or maintenance oriented 
environment are driven by the production schedule. However, 
the technique will only work if an accurate BOM and production 
schedule exist. 

The system that is proposed in this thesis is designed to 
provide the means for developing and maintaining an accurate 
data base. Additionally, it provides a model that will use 
that data effectively to generate a realistic materials fore- 
cast. 

The analysis of the temporary MRP system and its develop- 
ment as well as the design of the system proposed in this 
thesis have identified some problem areas that will have to 
be considered carefully in the course of implementing both 
of the systems. These problems are: 

1 . System Development 

The process of developing any system requires analysis 
and design by a team that has the time and competence to do 
the job. The implementation of the proposed system requires 
assignment of a team that will be responsible for reviewing 
the temporary system, preparing the detailed design for its 
successor and implementation. 
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2 . Planning Horizon 



The proposed system was designed to meet the constraints 
imposed by the current budgetary process and the quarterly 
preparation of the production schedule. This implies that the 
system does not have the capability to forecast long run re- 
quirements, nor can it provide all requirements, a procurement 
lead-time ahead to assure that all materials are purchased so 
that all scheduled jobs can be accomplishable. This situation 
can obviously be improved significantly by developing long run 
production schedules and trying to stick to them as much as 
possible. This appears feasible for at least the engine and 
components programs that represent a major part of the work- 
load schedule [21]. 

3 . Frequency of Requirements Generation 

Setting of the RSS stock levels is currently limited 
to once per quarter. This corresponds to the current frequency 
of determining the production schedule. It may be eventually 
useful, however, to regenerate the material requirements and 
reset levels on a monthly basis, thereby decreasing the influ- 
ence of the random part of the forecast. However, the system 
should be used at least for one year with the present frequency 
to determine its performance before any changes are made. 

4 . Coordination with the UICP 

The MRP forecast cannot be effective if the UICP 
system does not assure the existence of the required materials 
within the wholesale system. Since the problem is related to 
all NARF's and not just to Alameda it would be useful to 
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coordinate the operation o£ both systems so that the UICP 
could use the long-run forecasts from the MRP system as planned 
program requirements. 

5. ASKARS and NISTARS 

Although these two systems are being developed inde- 
pendently, there will undoubtedly be a need for communication 
between the systems. NISTARS will provide the storage space 
for the RSS and will also maintain a data-base which contains 
vital information for the NARF ' s day-to-day operations (for 
example, inventories on hand). Therefore, setting up an 
appropriate interface between the systems to allow direct 
access of one system to the other's data-base can simplify 
file maintenance in general and service to the users in 
particular . 

6. FIG'S and IIC's 

The practice of preparing the production schedule by 
FIG introduces uncertainty into the process of planning material 
requirements and complicates the maintenance of the MRP system. 
Transition to planning by IIG will make the whole process much 
more accurate and efficient. 

A rather different subject is the relationship between 
ASKARS and MRP. It so happened that the ASKARS system will 
become operational at the right time for implementation of the 
proposed MRP system. However, the interaction of two new 
systems may be very disastrous and therefore it is recommended 
that the actual implementation of the MRP system be delayed 
until most of ASKARS' "birth problems" have been resolved. 
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This delay time should be utilized to get better acquainted 
with the MRP system through the experience with the temporary 
system and to purify the data-base. This period should also 
be used for further analysis of the parameters needed for the 
proposed model. 

Another area that is related to the MRP system and 
requires further analysis is the policy of overhauling complex 
end-items, especially aircraft. The current policy is that 
whenever an end- item is overhauled its repairable components 
are also overhauled and placed back on the same aircraft. 

This delays the completion of the job and calls for inductions 
of components separately from the regular induction of such 
components being repaired and placed in the supply system. 

The MRP system would operate best if repaired components 
from stock were used in the aircraft overhaul and components 
from the aircraft that needed rework were returned to the 
supply system as non-ready- for- issue inventory. The advan- 
tage of this policy with respect to MRP is that it provides 
more accurate values for the replacement factors. As men- 
tioned earlier, it is desired to make the decision about this 
subject before conversion to the proposed system to save later 
changes in the BOM data. 

As to application of the project system to other activities, 
it appears that the model may be appropriate for other indus- 
trial activities to use. However, any action in that direction 
should probably not take place before the model proves its 
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effectiveness at NARF Alameda. Much will undoubtedly be 
learned which would serve to save time and effort for other 
applications . 
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APPENDIX A 



LIST OF SELECTED UADPS-SP FILES [18] 



1. 


Master Stock Item Record (MSIR) . 


This is the 




inventory status file. 






2. 


Planned Requirement/Reservation 


File 


(PR/RFS) . 


3. 


Receipt/Due File (R/D) . 






4. 


Requisition Status File (RSF) . 






5. 


Demand History File (DHF). Together 


with the 




represents the demand history. 






6. 


Address Master File.(AMF). 






7. 


Job Order File (JOF) . 






8. 


Master Employee Record (MER) . 






9. 


Receipt History File (RHF). 






10. 


Transaction/Reconstruction File 


(TRANSRECON) . 


11. 


Demand Master File (DMF) . 
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APPENDIX B 



SUPPORTING DATA ^ 

1 . Supporting Data 

The information to follow is required for estimating the 
size of files, processing times, and the required storage 
resources for the proposed system. The estimates are based 
on analyses of the present inventory system at NSCO and the 
temporary MRP application. 

General Data 

Approximate number of active FIC's = 10,000 

Approximate number of active IIC's = 14,000 

Maximum number of IIC's per FIG = 50 

Average number of consumable NSN’s per IIC = 50 

Maximum number of consumable NSN's per IIC = 1,200 

Average number of shops participating in IIC overhaul = 12 

Maximum number of shops per IIC (all that exist) = 150 

Number of active NSN’s (used by the NARF) = 35,000 

Number of active job orders = 28,000 

Number of material planners = 120 

2 . Transactions Volumes and Processing Frequencies 

Table B-1 describes the different software modules, and the 
type and volume of transactions processed by each module. 

T 

Obtained from personal interviews with LCDR W.P. Benefiel, 
500 Department, NARF Alameda, February 1980. 
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TABLE B-1 



Transactions, Volumes and Processing Frequencies 
for the Proposed MRP System 



Software Module 


Name of 

Transact ion/ Program 


Number of 
Trans act ions /Runs 


File maintenance 


BOM 






Induction data 


150,000 per year* 




Requis it ions 


200,000 per year* 




Estimation transac- 
tions 


10,000 per quarter 




BOM update run 


Once per quarter 




FIC to lie 






Translation Table 






QFT transactions 


40,000 per quarter 




Induction data 


150,000 per year 




Table update 


Once per quarter 


PCS 


Status transactions 


50,000 per quarter 




Expended hours 
transactions 


1,000,000 per qtr 




File maintenance run 


Weekly run 




Production schedule 
listing 


Monthly 




Exception report 


Monthly 




Queries 


3,000 per quarter 


Queries 


Inquire BOM by IIC 


8,000 per quarter 




Inquire BOM by FIC 


2,000 per quarter 




Inquire MRP forecast 


2,500 per quarter 




Modify MRP forecast 


500 per quarter 


Requirements 
generat ion 


Expended materials 
transactions 


30,000 per quarter 




"Raw” material 
requirements 


75,000 per quarter 




RSS level setting 
transactions 


20,000 per quarter 



*The figures are inflated to represent overload during war time 
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APPENDIX C 



SOFTWARE DEVELOPMENT 

1 . Software Development Activities 

The development of the MRP software will involve the 
following activities: - 

a. Design and Programming 

Detailed specifications have to be written for each 
software module, file and processing run. These specifica- 
tions will then be translated into computer programs which 
will be later tested to assure their compliance with the 
design . 

b. Conversion 

This phase involves preparations and actual conver- 
sion from the temporary MRP system to the proposed applica- 
tion. To do this, special programs will have to be written 
to convert the old data base to the new structure and to 
insert default values in those fields that did not exist 
before . 

Because of the nature of the application it is possible 
and very desirable to operate both systems in parallel for 
one quarter. However, when the final system is accepted it 
would be appropriate to have a short Cs3-y» two days') break 
in running the application. This period would allow all the 
transactions in the old system to be processed and the "live" ^ 
conversion to take place. 
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c. Testing 

This phase includes testing of individual software 
modules, programs and processing runs. Different transaction 
paths and options of the system should be tested to make sure 
that it all works as expected. 

The end of this phase involves a user’s acceptance 
test during which the user tests the system, and then accepts 
responsibility for normal operations if the test is success- 
fully passed. 

d. Parallel Operations 

While the old system is still running, the new one 
should run in parallel. This will allow the new system to 
be checked out before the old system is shut down. This 
phase also allows the users, and especially the material 
planners, to get acquainted with the new system, learn how 
to inquire and how to use the system's output. 

e. Documentation 

Documentation of the system should be done during 
the entire course of the project. At the early phases, the 
emphasis should be on documenting decisions and reasons for 
selecting specific options or procedures. In the later 
stages the emphasis should be on documentation of the soft- 
ware, data-base, input, output, and use of the system. 

The documentation should cover all modules, the 
interfaces between the modules and interrelation between the 
modules. Operational manuals should be provided describing 



157 



regular operations and actions to be taken when irregular 
events ("bugs”) occur. 

£. Training 

Involvement of the users in the early design stages 
will pay off when time for training comes. However, training 
should be provided to all users and people that are involved 
in running the system (operators, I/O clerks) to assure that 
they know how to handle the inputs and how to use the outputs 
and the services the system provides. 

g. Post Implementation Reviews 

After the system goes into normal operation, it would 
be very desirable to have at least one or two post implemen- 
tation reviews. These are meetings of the development team 
and the users in which problems are brought up and discussed. 
If there are problems, the group should identify its source 
and find a solution that will satisfy the users. However, it 
is advantageous to collect requests for small changes rather 
than implementing each one as it comes up. In addition, these 
changes should be examined to see if they are really needed. 

2 . Development Times 

The cost of the software development will be based on the 
size and complexity of the different modules [25]. The 
following productivity standards will be assumed in this 
process ; - 

1. Programming -- Fifty source, high- level - language state- 
ments per programmer per week (for simple level 1 
complexity programs). A statement in a simple program 
will be the "standard unit." 
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2. Testing -- 150 statements o£ complexity 1 per programmer 
per week. 

3. Documentation -- 15 percent of total programming and 
testing time. 

4. File Conversion -- approximately the same as file 
maintenance . 

5. Training and Parallel Operation -- two training days 
for each user/ operator . 

Table C-1 shows the derivation of the total size of the 
software (in "standard" statements) and allows derivation of 
the software development times as follows: - 

1. Programming time = 8650/50 = 173 man-weeks - 44 man-months. 

2. Testing time = 8650/150- 58 man-weeks ^ 14 man-months 
(8 programmer man-months and 4 analyst man-months). 

3. Documentation time - (44 + 11) x .15 8 man-months. 

4. File conversion time = (2250 + 300 + 1500)/50 - 81 man- 
weeks - 20 man-months (15 programmer man-months and 

5 analyst man-months). 

5. Training and parallel operations time involves: 

a. 0.5 programmer man-months. 

b. 0.2 analyst man-months. 

c. 0.2 operators man-months. 

d. 1.0 clerk man-months. 

In addition to that, analyst time is required for prepar- 
ing the detailed specifications for the MRP application. 

Based on the time that this study took, it is estimated that 
3 more man-months of analyst time are required. 

Adding together all elements gives the following times :- 

1. 75.5 programmer man-months. 

2. 14.2 analyst man-months. 
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TABLE C-1 



Software Size 



Module 


Program 


Source 

Statements 


Gomplexity 


Standard 

Units 


File 


BOM- -Input edit 


250 


1 


250 


Maintenance 


Extract 


50 


1 


50 




Update 


750 


3 


2250 




FIG to lie trans- 
lation table 










Extract 


50 


1 


50 




Update 


150 


2 


300 




PCS--Input edit 


250 


1 


250 




Update 


500 


3 


1500 


Queries 


Query "Driver" 


100 


2 


200 




Query BOM 


100 


2 


200 




Query MRP 
forecast 


300 


2 


600 




Modify MRP 
forecast 


500 


3 


1500 


Requirements 


Extract inputs 


50 


1 


50 


Generation 


Generate forecast 


250 


2 


500 




Reformat output 


50 


1 


50 




Generate 

transactions 


100 


1 


100 


Subroutines 


MRP subroutine 


150 


2 


300 


functions 
and report 
generators 


Read/write 

functions 


200 


2 


400 




lie from job 
order 


100 


1 


100 


Total 




3900 




1 

8650 
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3. 0.2 operator man-months. 

4. 1.0 clerk man-months. 

5. 8.0 material planners man-months (based on 120 planners). 

These figures imply that the implementation of the system 
in a period of one year requires the employment of six pro- 
grammers and one systems analyst. However, because the load 
is not equally distributed during the year it may well happen 
that at some times additional programmers (or overtime) and/or 
systems analysts will be needed. 
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APPENDIX D 



UPDATING REPLACEMENT FACTORS 

The replacement factor represents the proportion of a 
consumable item that is expected to be replaced when the end- 
item that includes that consumable is being replaced. The 
replacement factor is expected to change during the useful 
life of an end-item because of • 

1. Aging of the item; 

2. Changes in maintenance policies; 

3. Estimated replacement factors found to be in error. 

Consequently, there are two ways to update the replacement 

factor . 

1 . By Transaction 

The transactions that are submitted by the material 
planners (see BOM file maintenance) will set the "estimated 
replacement factor" field in the BOM file to the value reported 
in the transaction and will update the "estimator code" and 
"date of last estimate" as well. 

2 . By Actual Replacement Information 

During the BOM file maintenance run, actual replace- 
ment factors are computed. The actual replacement factor is 
the ratio between the total quantity of the item replaced in 
overhaul of a certain IIC and the total installed quantity 
of that consumable in the whole quantity that was inducted. 
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This new replacement factor will be used to update the 
’’actual replacement factor.” 

Various methods exist for updating information such 
as the replacement factors. The most simple would be to com- 
pute a weighted average of the new and the old replacement 
factors where the weights are proportional to induction 
quantities. A variation on that would be a simple moving 
average [29]. This method is utilized in the temporary MRP 
system. The Exponential Smoothing method is still another 
method often used in such cases. Its big advantage is that 
it needs no other data but the old and new factors and the 
smoothing constant. 

Forecasting usually involves a start-up problem. 

The information that is initially available is an estimate 
and the problem is how to phase it out and replace it by 
actual data as it becomes available. The intent of the pro- 
posed procedure for updating the replacement factors is to 
utilize information of both actual and estimated factors and 
to gradually phase in actual data so that as soon as suffi- 
cient actual experience is available the estimate will be 
ignored. To do that, two separate fields are maintained in 
each ’’consumable” trailer in the BOM file, one for the esti- 
mated replacement factor and the other for the actual factor. 
An additional field is used as a counter of the total induc- 
tion quantity on which the actual replacement factor is based. 
The contents of the estimate field are derived from 
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transactions, each new estimate for an I IC/consumable over- 
riding the previous one. The actual replacement factor is 
set to zero when the trailer is created and also whenever a 
new estimate is processed. At the first time an actual 
factor is computed, it will override the zero. In subsequent 
updates, a new actual replacement factor will be computed 
using exponential smoothing as follows: 



^N+1 



where , 



^N+1 "actual" replacement factor, 

is the old "actual" replacement factor, and 

is the actual replacement factor computed 
from last quarter’s data. 



The determination of the replacement factor to be 
used by a program will be done by a subroutine. This sub- 
routine will return to the calling program the replacement 
factor which results from the information in the fields con- 
taining the estimated factor, the actual factor, the date of 
estimation and the total induction quantity. The algorithm 
for determining the. replacement factor is as follows; 

1. If no actual factor exists, return the estimate. 

2. If an actual factor exists and the date of the estimate 

is more than a year old, return the actual factor. 

3. If the above conditions are not satisfied, compute the 

factor to be returned by exponentially smoothing the 
estimated and the actual replacement factors. The 
coefficient, a, to be used will be determined according 
to the total induction quantity. For example: 
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a. If the induction quantity is less tlian 10, a = 0.1; 



b. If the induction quantity is in the interval 
[10, 100] , a = 0.5; 

c. If the induction quantity is greater than 100, a = 1.0. 



The various parameters mentioned above, namely, the 
period before the estimate is totally phased out, and the 
intervals of total induction quantity for the variance a 
values, may have to be ’’tuned-up” after some experience is 
gained . 
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APPENDIX E 



FURTHER DISCUSSION OF THE PRM-MRP MODEL 



The Impact of a Budget Constraint 

Suppose that a budget constraint exists and assume that 
the 100% replaced items are all purchased. In addition, 
assume that after the 100% replaced items have been purchased, 
a limited remaining amount of money from the NSF is expected 
to be available to buy the items replaced less than 100% of 
the time. If we denote this remainder as B, then our con- 
straint on funds results in 

m 



where C^y^ is the total cost of buying y^ units of repair 
part No. i. 

If we solve for the individual values using equation (5) 
it is possible that these values will result in 

m 

Z C .y . > B . 
i = l ^ ^ 

However, this may not always be true and therefore it is 
appropriate to determine these "unconstrained" values of the 
different y's and test them against the constraint. If, 
indeed, the budget constraint is satisfied then we have the 
correct optimal y values. 
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If the budget constraint is not satisfied, the technique 
of Lagrange can be used to get a modified form of equation 
(5) ; namely. 



F(y) 



Cp ^ ^ [k ^ 9]C 

TT^ + kC 



(9) 



The approach is then to introduce trial values of 0, deter- 
mine the resulting set of y values using equation (9) , compute 
the associated sum 



m 

and compare it with B. If the sum is less than B the value 
of 0 should be reduced; if the sum is still greater than B 
the value of 0 should be increased. The search terminates 
when a value of 0 results in the sum being equal to B. The 
associated y^ values are the budget constrained optimal 
quantities of the m repair parts to place in the RSS. 

Is a Budget Constraint Appropriate ? 

The model developed above assumes a static situation in 
which the production schedule and the budget constraint are 
given. However, imposing both constraints in advance may 
have an adverse effect on the ability of the NARF to meet 
that schedule. It may well happen for a given component 
undergoing repair, that the items with 100% replacement will 
be available in stock whereas other items ffor which p < 1) 
would not be there. Consequently, what may happen is that 
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instead of having complete kits of parts required to complete 
a job there will be only "partial” kits, i.e., all the parts 
replaced 100% of the time and some of those where p < 1.0 . 

In such a case there is no way in which a job could be com- 
pleted. Moreover, those parts that are in stock may remain 
useless because of the shortage in other parts. 

The conclusion is that the proper way to go is to schedule 
jobs into the NARF so that the budget will be sufficient to 
provide all materials predicted by the model thereby, in fact, 
assuring that the constraint is not active. However, it might 
be logical to prepare a reserve of job orders for the case 
that actual consumption was lower than the forecast. The 
proper way to provide protection against such an event is to 
induct additional quantities of the items that have been 
inducted previously. 

Reducing the Number of Scheduled Jobs 
because of a Budget Constraint 

To avoid the problems described above, it would be 
natural to schedule jobs so that their material requirement 
would not exceed the budget vice changing the quantities of 
the materials placed in stock. To meet that goal, the orig- 
inal list of job orders should be split into groups of jobs, 
each group containing jobs of some priority. Then, the 
algorithm should be applied to each set of jobs to determine 
the budget it requires. When this step is completed, one 
can determine which jobs can be scheduled so that their 
material requirements would not exceed the budget, or on 



168 



the other hand, determine what increase in budget will allow 
the scheduling of some additional jobs. 

The Back-up Stock C^j from the Wholesale Supply System 

w is a variable quantity. Although the quantity of back- 
up stock is known at the start of the quarter or when planning 
occurs, the amount available at the time it is needed depends 
among others, on the demand the item experienced from other 
activities during the time from the start of the quarter until 
the time when the shortage occurred. It may be appropriate 
to use as w the amount of the item prepositioned as war 
reserves. However, this assumption requires having a per- 
mission to actually use that stock in the event that a short- 
age occurs in the RSS stock and the quantity in the regular 
wholesale supply is insufficient. 

Perhaps a sensitivity analysis will provide guidance as 
to the appropriate assumptions to make about the value of w. 

Which Constants to Use 

The model requires the following constants: 

C - Processing costs 
P ^ 

- Holding costs 

TT^ - Shortage cost for item obtained from local 
^ wholesale supply 

TT^ - Shortage costs for items obtained somewhere else 
k - Surplus cost factor 

It is logical to assume that these constants have specific 
values for each item used in repair of a component. It is 
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relatively simple to determine the values of C and C, and 

p h 

it may as well be logical to apply these constants to groups 
of items of similar nature. This is not the case, however, 
with iTj^, tt 2 , and k. The shortage cost depends not only on 
the item that is not available but also on the specific 
circumstances of a given job that requires the part and on 
the circumstances of other jobs. That is also true for k. 
Consequently, ir^, and k may vary from job to job, from 

part to part, and even from time to time for the same job/ 
part. It may be useful to note that k can be viewed as the 
"knob” that adjusts the surplus cost [see equation (9)] in 
much the same way as is done in the UICP model where the 
"knob" is the shortage cost. Also, when a budget constraint 
is imposed, it may be viewed as increasing the value of the 
surplus cost resulting from k, causing a solution for y more 
in favor of a shortage. 



Pragmatic Aspect 

Maintaining the different constants for each item and, 
in particular, having it done by the NARF, would be prohib- 
itively complicated. The system may become significantly 
more simple if the constants could be determined for groups 
of items rather than for each item. It seems logical to begin 
by establishing values spanning groups of items C^nd keeping 
those constants in a table that will be shared by different 
application programs). 



170 



LIST OF REFERENCES 



1. Greene, James H. , Production and Inventory Control 
Handbook , McGraw-Hill Book Company, New York, 1970. 

2. Moore, Franklin G. and Hendrick, T.E., Production/Oper- 
ations Management , Irwin Inc., Homewood, Illinois, 1977. 

3. Nolan, R.L. and Gibson, C.F., Managing the Four Steps of 
EDP Growth. M.I.S.--A Managerial Prospective , pp. 152- 
165, Science Research Associates, Inc., Chicago, 1977. 

4. Orlicky, Joseph, Material Requirements Planning , McGraw- 
Hill Book Company, New York, 1975. 

5. Plossl , G.W. and Wight, O.W., Production and Inventory 
Control , Prentice- Hall , Englewood Cliffs, N. J . , 1967 . 

6. Tersine, Richard J., Materials Management and Inventory 
Systems , North-Holland Publishing Company, New York, 1976. 

7. Navy Supply Center Oakland, Wholesale Supply Support 
Consolidation and Warehouse Modernization Plan, 23 March 
1979. 

8. Office of the Assistant Secretary of Defense, Installa- 
tions and Logistics, Volume II, Part I, United States 
Navy Supply System Description , Working Group Report, 

March 1976. 

9. Office of the Assistant Secretary of Defense, Installa- 
tions and Logistics, Volume II, Part II, United States 
Navy Supply System Description , Working Group Report, 

April 1976. 

10. Briefing presented to Mr. G.D. Hooper of the 0MB by 
NAVAIREWORKFAC Code 502, on 7 June 1979. 

11. Whybark, D.C. and Williams, J.G., Material Requirements 
Planning Under Uncertainty. Decision Sciences, Volume 7, 
No. 4, 1976. 

12. Donelson, William S., MRP- -Who Needs It . Datamation, 

May 1979. 

13. Smith, Carl G., Introducing Net Change MRP . Computer 
Decisions, Vol. 9, No. 10, pp 32-37, October 1977. 

14. Hadley, G. and Whitin, T.M. , Analysis of Inventory Systems . 
Prentice-Hall, Inc., Englewood Cliffs, N.J., 1963. 



171 



15 . 



Niland, Powell, Production Planning, Scheduling and 
Inventory Control . The Macmillan Company, Collier- 
Macmillan Limited, London, 1970. 

16. Gavett, William J. , Production and Operation Management . 
Harcourt, Brace 5 World, Inc., New York, 1968. 

17. Night, Oliver W. , Production and Inventory Management in 
the Computer Age . Cahners Books International, Inc., 
Boston, 1974. 

18. Fleet Material Support Office., UADPS-SP Executive 
Handbook . 

19. Naval Air Rework Facility Alameda, Code 029, memorandum, 
subject: NAS/NSC Supply Consolidation; General Informa- 
tion Concerning , 13 November 1979. 

20. Naval Air Rework Facility Alameda, Code 502, subject: 
Application of MRP Techniques to the Generation of a 
Local OSI , 20 July 1979. 

21. Hoffman, Lee D. , Operational Support Inventory for Naval 
Air Rework Facility Alameda . M.S. Thesis, Naval Post- 
graduate School, Monterey, California, 1979. 

22. Naval Air Rework Facility Alameda: GPER ITEM A9-GG-001 
ASKARS Specifications , 1 May 1979. 

23. Guidry, F., NARF Alameda Code 0212 system analyst, 
personal interview of 18 Jan 1980. 

24. Woolsey, Gene, Ten Ways to Go Down with MRP . Interfaces, 
Vol. 9, No. 5, pp 77-80, November 1979. 

25. Wolverton, R.W., The Cost of Developing Large Scale 
Software . IEEE Transactions on Computers, pp . 615-635 , 
June 1974. 

26. NAVAIR Form 11010/2A, General Plant Equipment Analysis 
Worksheet . 

27. Ostle, B. and Mensing, R.W. , Statistics in Research . The 
Iowa State University Press, Ames, 1975. 

28. McMasters, A.W. , A Repair Parts Inventory Model for a 
Naval Air Rework Facility . Research Report No . NPS- 54-80-04, 
Naval Postgraduate School, Monterey, CA, 1980. 

29. Brown, R.G., Statistical Forecasting for Inventory Control . 
McGraw-Hill, New York, 1959. 



172 



I 



I 



« 

<1 



0 



INITIAL DISTRIBUTION LIST 

No. Copies 



1. Defense Technical Information Center 2 

Cameron Station 

Alexandria, Virginia 22314 

2. Defense Logistics Studies Information Exchange 1 
U.S. Army Logistics Management Center 

Fort Lee, Virginia 23807 

3. Library, Code 0142 2 

Naval Postgraduate School 

Monterey, California 93940 

4. Department Chairman, Code 54 Js 1 



Department of Administrative Sciences 
Naval Postgraduate School 
Monterey, California 93940 

5. Department Chairman, Code 52 Bz 1 

Department of Computer Science 

Naval Postgraduate School 
Monterey, California 93940 

6. Associate Professor A. W. McMasters, Code 54 Mg 5 
Department of Administrative Sciences 

Naval Postgraduate School 
Monterey, California 93940 

7. Professor N. F. Schneidewind, Code 52 Ss 1 

Department of Administrative Sciences 

Naval Postgraduate School 
Monterey, California 93940 

8. Professor R. W. Sagehorn, Code 54 Sn 1 

Department of Administrative Sciences 

Naval Postgraduate School 
Monterey, California 93940 

9. LCDR Baruch Eylon, Israeli Navy 2 

Embassy of Israel 

Naval Attache 
1621 - 22nd St. NW 
Washington, D.C., 20008 



173 



4 



10. Embassy of Israel 
Naval Attache 
1621 * 22nd St. NW 
Washington, D.C., 200Q8 

11. LCDR W. P. Benefiel, Code 502 1 

Naval Air Rework Facility 

NAS Alameda, California 94501 

12. CDR Robert D. Grant 5 

Special Project Officer ^Code 08) 

Naval Supply Center 
Oakland, California 94625 

13. Mr. H. J. Lieberman, Code 0431B 1 

Naval Supply Systems Command 

Washington, D.C., 20376 



\ 




1 7yl 



187118 7118 



Thesis 

E965 Eylon 

c.l A proposed material 

requirements planning “^9 
system for NARF 
Alameda. 



20 64 

26 APR d9 
15 Aiir» no 



? 9 4 5 

■S9h9i 7 



Thes i s 

E965 

c.l 



Eylon 



187118 



A proposed material 
requirements planning 
system for NARF 
A1 ameda. 



rpwpLed material 




* 



•l 



